added skills etc
This commit is contained in:
45
.agents/skills/evolv-database-influx-architecture/SKILL.md
Normal file
45
.agents/skills/evolv-database-influx-architecture/SKILL.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
name: evolv-database-influx-architecture
|
||||||
|
description: Design and review EVOLV data modeling and storage architecture for telemetry and dashboard consumption. Use when deciding InfluxDB measurement/tag/field schemas, retention/downsampling strategy, write/read payload structures, and Grafana query compatibility for Node-RED outputs.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV Database Influx Architecture
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Shape telemetry data so it is queryable, performant, and maintainable for operations dashboards and analytics.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- Output payload structure from EVOLV nodes
|
||||||
|
- InfluxDB write model: measurement, tags, fields, timestamp policy
|
||||||
|
- Retention/downsampling implications for Grafana visualization
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
1. Classify data by usage:
|
||||||
|
- real-time control
|
||||||
|
- operator dashboarding
|
||||||
|
- long-term analytics
|
||||||
|
2. Define stable schema conventions:
|
||||||
|
- measurement naming
|
||||||
|
- tag cardinality controls
|
||||||
|
- numeric fields and units
|
||||||
|
3. Validate that node outputs map cleanly to write model.
|
||||||
|
4. Check query ergonomics for expected Grafana panels.
|
||||||
|
5. Specify retention/downsampling and backfill behavior.
|
||||||
|
|
||||||
|
## Design Rules
|
||||||
|
- Avoid high-cardinality tags for volatile identifiers.
|
||||||
|
- Keep units explicit and consistent over time.
|
||||||
|
- Prefer additive schema evolution; document breaking changes.
|
||||||
|
- Include timestamps that are consistent across nodes.
|
||||||
|
|
||||||
|
## Test/Validation Expectations
|
||||||
|
- Verify sample payloads produce intended point shape.
|
||||||
|
- Check representative queries for latency and result correctness.
|
||||||
|
- Include migration strategy when schema changes are unavoidable.
|
||||||
|
|
||||||
|
## Deliverables
|
||||||
|
Return:
|
||||||
|
- proposed schema (measurement/tags/fields)
|
||||||
|
- rationale tied to dashboard and analytics use
|
||||||
|
- changed files/tests
|
||||||
|
- migration and retention plan
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Database + Influx Architect"
|
||||||
|
short_description: "Design telemetry schema for Influx and Grafana"
|
||||||
|
default_prompt: "Define EVOLV telemetry modeling, Influx measurement/tag/field choices, retention strategy, and Grafana-compatible query shape."
|
||||||
54
.agents/skills/evolv-frontend-node-red/SKILL.md
Normal file
54
.agents/skills/evolv-frontend-node-red/SKILL.md
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
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.
|
||||||
|
|
||||||
|
## 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
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Frontend + Node-RED"
|
||||||
|
short_description: "Build EVOLV Node-RED editor/runtime UX safely"
|
||||||
|
default_prompt: "Implement EVOLV Node-RED editor HTML and runtime config mapping with strict UI/runtime parity, stable endpoint contracts, and tests."
|
||||||
42
.agents/skills/evolv-instrumentation-assets/SKILL.md
Normal file
42
.agents/skills/evolv-instrumentation-assets/SKILL.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
name: evolv-instrumentation-assets
|
||||||
|
description: Engineer measurement and instrumentation behavior for EVOLV assets. Use when defining sensor mappings, tag semantics, data quality checks, measurement container behavior, calibration assumptions, and measurement-driven node logic in `measurement` and related assets.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV Instrumentation Assets
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Ensure measurements are trustworthy, well-modeled, and usable by control and analytics logic.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- `nodes/measurement/`
|
||||||
|
- `nodes/generalFunctions/src/helper/measurement*`
|
||||||
|
- `nodes/generalFunctions/datasets/assetData/measurement.json`
|
||||||
|
- Any node consuming measurement topics or quality flags
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
1. Inventory required measurements by asset/function.
|
||||||
|
2. Define tag semantics and expected units.
|
||||||
|
3. Add validation rules for bounds, type, and missing values.
|
||||||
|
4. Specify handling for stale/noisy/bad-quality signals.
|
||||||
|
5. Ensure downstream nodes receive consistent payload structure.
|
||||||
|
|
||||||
|
## Standards
|
||||||
|
- Prefer explicit unit naming and conversion points.
|
||||||
|
- Separate raw sensor value from engineered value when possible.
|
||||||
|
- Avoid hidden coercions that mask instrumentation faults.
|
||||||
|
- Record assumptions around calibration and sensor placement.
|
||||||
|
|
||||||
|
## Test Expectations
|
||||||
|
Cover:
|
||||||
|
- missing/invalid payloads
|
||||||
|
- unit conversion correctness
|
||||||
|
- quality/state transitions (good/suspect/bad)
|
||||||
|
- behavior when critical measurements drop out
|
||||||
|
|
||||||
|
## Deliverables
|
||||||
|
Return:
|
||||||
|
- measurement dictionary (name, unit, validity range, source)
|
||||||
|
- validation and fallback rules
|
||||||
|
- file/test changes
|
||||||
|
- open instrumentation risks for commissioning
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Instrumentation Engineer"
|
||||||
|
short_description: "Define sensor and measurement asset behavior"
|
||||||
|
default_prompt: "Design instrumentation mappings, units, validation, quality handling, and robust measurement-driven logic for EVOLV assets."
|
||||||
45
.agents/skills/evolv-mechanical-rotating-equipment/SKILL.md
Normal file
45
.agents/skills/evolv-mechanical-rotating-equipment/SKILL.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
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.
|
||||||
|
|
||||||
|
## 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
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Rotating Equipment Engineer"
|
||||||
|
short_description: "Model rotating assets with physical realism"
|
||||||
|
default_prompt: "Review and implement rotating-machine logic with unit consistency, envelope constraints, failure-safe behavior, and regression tests."
|
||||||
52
.agents/skills/evolv-orchestrator/SKILL.md
Normal file
52
.agents/skills/evolv-orchestrator/SKILL.md
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
name: evolv-orchestrator
|
||||||
|
description: Orchestrate multi-agent execution for the EVOLV repository. Use when work spans multiple disciplines (Node-RED frontend/editor UI, rotating equipment logic, instrumentation assets, process control, InfluxDB/data architecture, OT/IT security, and quality/technical debt) and requires decomposition, sequencing, handoffs, and integration decisions.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV Orchestrator
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Coordinate specialized EVOLV agents, split work into clear tasks, and ensure integrations are coherent across JavaScript/CommonJS Node-RED nodes, process assets, and observability/data concerns.
|
||||||
|
|
||||||
|
## Execution Flow
|
||||||
|
1. Frame the objective and constraints in one paragraph.
|
||||||
|
2. Identify impacted areas in the repo before assigning work:
|
||||||
|
- `nodes/<nodeName>/<nodeName>.html` (editor UI)
|
||||||
|
- `nodes/<nodeName>/<nodeName>.js` (runtime entry)
|
||||||
|
- `nodes/<nodeName>/src/nodeClass.js` (Node-RED wrapper)
|
||||||
|
- `nodes/<nodeName>/src/specificClass.js` (domain logic)
|
||||||
|
- `nodes/generalFunctions/` (shared helpers/config)
|
||||||
|
3. Route tasks to specialist skills with explicit deliverables and acceptance criteria.
|
||||||
|
4. Require each specialist to return:
|
||||||
|
- assumptions
|
||||||
|
- changed files
|
||||||
|
- tests added/updated
|
||||||
|
- unresolved risks
|
||||||
|
5. Integrate outputs and check cross-skill consistency:
|
||||||
|
- config fields aligned between `.html` and runtime parsing
|
||||||
|
- admin endpoints stable (`/<nodeName>/menu.js`, `/<nodeName>/configData.js`)
|
||||||
|
- topic contracts (`msg.topic`) unchanged unless migration is defined
|
||||||
|
6. Ask targeted user interview questions only when decisions are ambiguous and unblock execution.
|
||||||
|
7. Produce a final integrated plan or implementation with a risk log.
|
||||||
|
|
||||||
|
## Delegation Map
|
||||||
|
- Use `evolv-frontend-node-red` for Node-RED editor/runtime UX and HTML config input design.
|
||||||
|
- Use `evolv-mechanical-rotating-equipment` for rotating machine behavior, limits, and performance logic.
|
||||||
|
- Use `evolv-instrumentation-assets` for measurement tags, sensor semantics, and asset metadata.
|
||||||
|
- Use `evolv-process-systems-control` for system-level interactions, modes, and control architecture.
|
||||||
|
- Use `evolv-database-influx-architecture` for InfluxDB schema, retention, query shape, and Grafana coupling.
|
||||||
|
- Use `evolv-ot-it-security` for OT/IT hardening and secure-by-default checks.
|
||||||
|
- Use `evolv-quality-technical-debt` for regression risk, tests, maintainability, and technical debt.
|
||||||
|
|
||||||
|
## Interview Protocol
|
||||||
|
Ask at most 3 focused questions at a time. Prioritize:
|
||||||
|
1. Operational objective and KPI (what "better" means).
|
||||||
|
2. Safety/availability constraints (what must never break).
|
||||||
|
3. Backward compatibility expectations for flows and topics.
|
||||||
|
|
||||||
|
## Output Contract
|
||||||
|
Return:
|
||||||
|
- task breakdown by specialist
|
||||||
|
- execution order and dependencies
|
||||||
|
- measurable acceptance criteria
|
||||||
|
- integration risks and mitigation
|
||||||
4
.agents/skills/evolv-orchestrator/agents/openai.yaml
Normal file
4
.agents/skills/evolv-orchestrator/agents/openai.yaml
Normal file
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Orchestrator"
|
||||||
|
short_description: "Coordinate EVOLV specialist agent workflows"
|
||||||
|
default_prompt: "Break EVOLV work into specialist tasks, sequence execution, ask focused clarifying questions when needed, and return integrated acceptance criteria with risks."
|
||||||
43
.agents/skills/evolv-ot-it-security/SKILL.md
Normal file
43
.agents/skills/evolv-ot-it-security/SKILL.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
name: evolv-ot-it-security
|
||||||
|
description: Perform OT/IT security analysis for EVOLV Node-RED automation systems. Use when reviewing admin endpoints, node input handling, configuration exposure, dependency risk, network/data flow boundaries, and secure-by-default behavior for operational technology integrations.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV OT/IT Security
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Identify and reduce security risk while preserving operational reliability for process automation workloads.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- Node-RED admin endpoints in node entry files
|
||||||
|
- Input validation across `msg.topic` and payload paths
|
||||||
|
- Exposure of sensitive config/secrets in code, logs, or UI
|
||||||
|
- Dependency and supply-chain concerns in node packages
|
||||||
|
|
||||||
|
## Security Workflow
|
||||||
|
1. Enumerate attack surface:
|
||||||
|
- HTTP admin routes
|
||||||
|
- message ingress topics/payloads
|
||||||
|
- external service interfaces
|
||||||
|
2. Validate input sanitization and type checks.
|
||||||
|
3. Check least-privilege assumptions and secret handling.
|
||||||
|
4. Evaluate failure modes for denial-of-service or unsafe operation.
|
||||||
|
5. Recommend pragmatic controls with minimal operational friction.
|
||||||
|
|
||||||
|
## Control Priorities
|
||||||
|
- Reject malformed or unauthorized control messages.
|
||||||
|
- Avoid leaking credentials, asset identifiers, or internal topology.
|
||||||
|
- Keep defaults safe; require explicit opt-in for risky behavior.
|
||||||
|
- Preserve auditability of critical control actions.
|
||||||
|
|
||||||
|
## Validation Expectations
|
||||||
|
- Add negative tests for malformed inputs and unauthorized paths.
|
||||||
|
- Confirm error paths are explicit and non-sensitive.
|
||||||
|
- Document residual risk when controls are deferred.
|
||||||
|
|
||||||
|
## Deliverables
|
||||||
|
Return:
|
||||||
|
- findings sorted by severity
|
||||||
|
- concrete remediation plan by file
|
||||||
|
- tests added for security regressions
|
||||||
|
- residual risks and compensating controls
|
||||||
4
.agents/skills/evolv-ot-it-security/agents/openai.yaml
Normal file
4
.agents/skills/evolv-ot-it-security/agents/openai.yaml
Normal file
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV OT/IT Security Engineer"
|
||||||
|
short_description: "Audit EVOLV OT/IT control security posture"
|
||||||
|
default_prompt: "Perform EVOLV OT/IT security review of endpoints, message inputs, secret handling, and safe-default controls with severity-ranked fixes."
|
||||||
49
.agents/skills/evolv-process-systems-control/SKILL.md
Normal file
49
.agents/skills/evolv-process-systems-control/SKILL.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
name: evolv-process-systems-control
|
||||||
|
description: Design and review system-level control behavior across EVOLV process nodes. Use when coordinating multi-node interactions, mode/state transitions, parent-child registration flows, control loops, and complex process sequencing spanning reactors, valves, pumps, settlers, and machine groups.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV Process Systems Control
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Preserve stable system-wide behavior across interacting Node-RED nodes and process assets.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- Cross-node interactions via `msg.topic`
|
||||||
|
- Parent-child registration contracts (`registerChild` and related topics)
|
||||||
|
- Mode management and sequencing in node wrappers/domain classes
|
||||||
|
|
||||||
|
## Message/Port Convention Baseline
|
||||||
|
Many EVOLV nodes use this output convention:
|
||||||
|
- output 0: process message
|
||||||
|
- output 1: database/influx message
|
||||||
|
- output 2: parent/registration/control plumbing
|
||||||
|
|
||||||
|
Preserve topic stability once released (`registerChild`, `setMode`, `setScaling`, etc). If a topic contract changes, define a migration path.
|
||||||
|
|
||||||
|
## Control Workflow
|
||||||
|
1. Map control boundaries and authority (who commands whom).
|
||||||
|
2. List topic contracts and payload schemas.
|
||||||
|
3. Verify state/mode transition logic for race/conflict conditions.
|
||||||
|
4. Define safe startup, shutdown, and failover behavior.
|
||||||
|
5. Confirm tick timing and output ordering assumptions.
|
||||||
|
|
||||||
|
## Design Rules
|
||||||
|
- Keep topic names stable once released.
|
||||||
|
- Use explicit transition guards and default-safe modes.
|
||||||
|
- Avoid hidden cross-coupling between unrelated assets.
|
||||||
|
- Make control intent observable in outputs/status.
|
||||||
|
|
||||||
|
## Test Expectations
|
||||||
|
Add tests for:
|
||||||
|
- normal sequence transitions
|
||||||
|
- out-of-order messages
|
||||||
|
- duplicate child registration and dedupe behavior
|
||||||
|
- fail-safe behavior under missing dependencies
|
||||||
|
|
||||||
|
## Deliverables
|
||||||
|
Return:
|
||||||
|
- system interaction map (topics + ownership)
|
||||||
|
- transition table and safety guards
|
||||||
|
- changed files/tests
|
||||||
|
- unresolved control hazards with mitigation suggestions
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Systems Control Engineer"
|
||||||
|
short_description: "Design robust multi-node process control"
|
||||||
|
default_prompt: "Engineer EVOLV system-wide control topics, mode transitions, sequencing, and fail-safe operation across interacting process nodes."
|
||||||
52
.agents/skills/evolv-quality-technical-debt/SKILL.md
Normal file
52
.agents/skills/evolv-quality-technical-debt/SKILL.md
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
name: evolv-quality-technical-debt
|
||||||
|
description: Drive code quality, regression prevention, and technical debt management for EVOLV nodes. Use when reviewing changes for bugs, maintainability, test completeness, architectural drift, and when creating prioritized remediation plans for JavaScript/CommonJS Node-RED modules.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EVOLV Quality Technical Debt
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
Raise delivery reliability by detecting defects early and systematically reducing technical debt in EVOLV nodes.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- Node implementation quality in `nodes/<nodeName>/src/`
|
||||||
|
- Editor/runtime contract consistency in `.html` + runtime wrappers
|
||||||
|
- Shared utility hygiene in `nodes/generalFunctions/`
|
||||||
|
- Test depth in `nodes/<nodeName>/test/`
|
||||||
|
|
||||||
|
## Test Policy Baseline
|
||||||
|
All code changes require tests under `nodes/<nodeName>/test/`.
|
||||||
|
|
||||||
|
Cover at minimum:
|
||||||
|
- config default/override behavior and numeric coercion
|
||||||
|
- each supported `msg.topic` handler with edge cases
|
||||||
|
- child registration and dedupe side effects
|
||||||
|
- tick/output boundaries and error paths
|
||||||
|
- regression tests for fixed bugs
|
||||||
|
|
||||||
|
Execution:
|
||||||
|
- preferred: `node --test nodes/<nodeName>/test/*.test.js`
|
||||||
|
- fallback: `node nodes/<nodeName>/test/<file>.test.js`
|
||||||
|
|
||||||
|
## Review Workflow
|
||||||
|
1. Assess correctness risks first (runtime errors, logic regressions, broken topic contracts).
|
||||||
|
2. Assess maintainability (duplication, unclear ownership, implicit behavior).
|
||||||
|
3. Assess test adequacy against EVOLV policy:
|
||||||
|
- config defaults/overrides
|
||||||
|
- topic handlers and edge cases
|
||||||
|
- tick/output boundaries
|
||||||
|
- regressions for fixed bugs
|
||||||
|
4. Create a prioritized debt backlog with effort and impact.
|
||||||
|
|
||||||
|
## Quality Criteria
|
||||||
|
- Domain logic remains testable without full Node-RED runtime.
|
||||||
|
- Complex logic is explicit and minimally coupled.
|
||||||
|
- Backward compatibility is deliberate and documented.
|
||||||
|
- New behavior includes tests that fail before and pass after.
|
||||||
|
|
||||||
|
## Deliverables
|
||||||
|
Return:
|
||||||
|
- findings by severity
|
||||||
|
- test gaps and specific cases to add
|
||||||
|
- debt backlog (now/next/later)
|
||||||
|
- recommended refactors with expected payoff
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "EVOLV Quality + Debt Engineer"
|
||||||
|
short_description: "Drive code quality and technical debt reduction"
|
||||||
|
default_prompt: "Review EVOLV code for defects, regression risk, test gaps, and maintainability issues; provide prioritized remediation."
|
||||||
71
AGENTS.md
Normal file
71
AGENTS.md
Normal file
@@ -0,0 +1,71 @@
|
|||||||
|
# EVOLV Agent Guide (AGENTS.md)
|
||||||
|
|
||||||
|
## Project Summary
|
||||||
|
EVOLV is a modular Node-RED package bundling multiple custom control/automation nodes (primarily under `nodes/`) for wastewater/process applications.
|
||||||
|
|
||||||
|
## Repository Layout
|
||||||
|
- `package.json`: Root package metadata + `node-red.nodes` map that tells Node-RED which node entrypoints to load.
|
||||||
|
- `nodes/<nodeName>/`: A Node-RED node module (often a git submodule).
|
||||||
|
- `<nodeName>.js`: Node-RED runtime entry (registers the node and exposes admin endpoints).
|
||||||
|
- `<nodeName>.html`: Node-RED editor UI definition for the node.
|
||||||
|
- `src/`: Node implementation classes and logic.
|
||||||
|
- `nodes/generalFunctions/`: Shared utilities used by most nodes (logger/config/menu helpers, etc).
|
||||||
|
- `node_modules/`: Local install output; do not edit.
|
||||||
|
|
||||||
|
## Agent Knowledge Base
|
||||||
|
- `.agents/`: Root directory for repository-specific agent definitions and knowledge base content (non-runtime/support assets, not Node-RED production code).
|
||||||
|
- `.agents/skills/`: EVOLV specialist skills (domain instructions, workflows, and orchestrator logic).
|
||||||
|
- When tasks involve domain reasoning or specialist routing, prefer `.agents/skills/*/SKILL.md` as the primary in-repo source of guidance.
|
||||||
|
|
||||||
|
## Agent Invocation Policy
|
||||||
|
- Default: always invoke orchestrator first via `.agents/skills/evolv-orchestrator/SKILL.md`.
|
||||||
|
- Orchestrator decides specialist selection, task decomposition, execution order, and integration checks.
|
||||||
|
- Direct specialist invocation is allowed only when all are true:
|
||||||
|
- task is clearly single-domain
|
||||||
|
- expected impact is local (single node/module concern)
|
||||||
|
- no cross-node contract/topic/schema/security implications
|
||||||
|
- If uncertainty exists, fall back to orchestrator.
|
||||||
|
|
||||||
|
## Agent Routing Table
|
||||||
|
Use this table after orchestrator triage, or for approved single-domain direct calls.
|
||||||
|
|
||||||
|
| Task Pattern | Primary Skill | Path |
|
||||||
|
|---|---|---|
|
||||||
|
| Multi-domain feature, ambiguous ownership, or cross-node integration planning | Orchestrator | `.agents/skills/evolv-orchestrator/SKILL.md` |
|
||||||
|
| Node-RED editor HTML, form defaults, menu/config endpoints, UI/runtime config parity | Frontend + Node-RED expert | `.agents/skills/evolv-frontend-node-red/SKILL.md` |
|
||||||
|
| Rotating machine behavior, pump curves, operating envelopes, mechanical plausibility | Mechanical rotating equipment engineer | `.agents/skills/evolv-mechanical-rotating-equipment/SKILL.md` |
|
||||||
|
| Sensor/measurement semantics, units, validation, quality flags, measurement assets | Instrumentation engineer | `.agents/skills/evolv-instrumentation-assets/SKILL.md` |
|
||||||
|
| System-wide control architecture, sequencing, mode transitions, parent-child topic contracts | System/process control engineer | `.agents/skills/evolv-process-systems-control/SKILL.md` |
|
||||||
|
| InfluxDB telemetry model, tags/fields, retention, Grafana query compatibility | Database/Influx architect | `.agents/skills/evolv-database-influx-architecture/SKILL.md` |
|
||||||
|
| OT/IT threat review, secure defaults, endpoint hardening, control-message safety | OT/IT security engineer | `.agents/skills/evolv-ot-it-security/SKILL.md` |
|
||||||
|
| Code quality review, regression risk, test gaps, technical debt prioritization | Quality/debt engineer | `.agents/skills/evolv-quality-technical-debt/SKILL.md` |
|
||||||
|
|
||||||
|
## Shared Engineering Baseline
|
||||||
|
- Dependencies: prefer `npm ci` at repo root (uses `package-lock.json`). Avoid changing `package.json` without updating the lockfile.
|
||||||
|
- Node-RED integration (local dev):
|
||||||
|
- Ensure Node-RED can see this repo as a nodes directory (e.g., `settings.js` with `nodesDir: './nodes'`) or copy/link the repo into `~/.node-red/nodes/`.
|
||||||
|
- Restart Node-RED after changes so nodes reload.
|
||||||
|
|
||||||
|
## Submodules
|
||||||
|
Many `nodes/*` directories are git submodules.
|
||||||
|
- Prefer making changes in the appropriate submodule directory and keep edits scoped to that node.
|
||||||
|
- Avoid editing `nodes/*/.git` files directly.
|
||||||
|
- If the task is “update a node submodule”, update the submodule pointer in this repo rather than copying code across nodes.
|
||||||
|
|
||||||
|
## Safety / Hygiene
|
||||||
|
- Do not modify generated or vendored content unless explicitly requested:
|
||||||
|
- `node_modules/`
|
||||||
|
- `EVOLV-*.tgz`
|
||||||
|
- Exclude `node_modules/` when searching or refactoring (`rg --glob '!**/node_modules/**'`).
|
||||||
|
- Network access may be restricted in automated runs; avoid installing from git/NPM without approval.
|
||||||
|
|
||||||
|
## Validation
|
||||||
|
No centralized test runner is configured at the root.
|
||||||
|
- Prefer targeted smoke checks: Node-RED starts, nodes load, node editor renders, and admin endpoints respond.
|
||||||
|
- If a node has its own `package.json` scripts, run them from that node directory only when they actually execute in your environment.
|
||||||
|
|
||||||
|
## Skill Ownership Of Detailed Standards
|
||||||
|
- Node-RED structure, file responsibilities, admin endpoints, and new-node checklist: `.agents/skills/evolv-frontend-node-red/SKILL.md`
|
||||||
|
- Message/port conventions and topic contract behavior: `.agents/skills/evolv-process-systems-control/SKILL.md`
|
||||||
|
- Test policy depth and quality gates: `.agents/skills/evolv-quality-technical-debt/SKILL.md`
|
||||||
|
- Multi-skill decomposition/integration and interview protocol: `.agents/skills/evolv-orchestrator/SKILL.md`
|
||||||
BIN
EVOLV-1.0.20.tgz
BIN
EVOLV-1.0.20.tgz
Binary file not shown.
BIN
EVOLV-1.0.28.tgz
Normal file
BIN
EVOLV-1.0.28.tgz
Normal file
Binary file not shown.
16
nodes/EXAMPLES.md
Normal file
16
nodes/EXAMPLES.md
Normal file
@@ -0,0 +1,16 @@
|
|||||||
|
# Node Examples
|
||||||
|
|
||||||
|
This index tracks per-node example flows intended for quick operational understanding.
|
||||||
|
|
||||||
|
## RotatingMachine
|
||||||
|
|
||||||
|
Path: `nodes/rotatingMachine/examples/`
|
||||||
|
|
||||||
|
- `basic.flow.json`
|
||||||
|
Manual controls + local charts for core behavior.
|
||||||
|
- `integration.flow.json`
|
||||||
|
Extended scenario controls and richer observability.
|
||||||
|
- `edge.flow.json`
|
||||||
|
Boundary/error-driving controls to inspect resilience.
|
||||||
|
|
||||||
|
See `nodes/rotatingMachine/examples/README.md` for details.
|
||||||
Submodule nodes/dashboardAPI updated: c99a93f73b...1ea4788848
Submodule nodes/generalFunctions updated: 067017f2ea...1cfb36f604
Submodule nodes/machineGroupControl updated: f4cb329597...0430471dca
Submodule nodes/measurement updated: 339ae6bdde...f979b1ae2b
Submodule nodes/monster updated: 3971b4e328...6b58dd4bd5
Submodule nodes/rotatingMachine updated: 108d2e23ca...c63701db38
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "EVOLV",
|
"name": "EVOLV",
|
||||||
"version": "1.0.20",
|
"version": "1.0.28",
|
||||||
"description": "Modular Node-RED package containing all control and automation nodes developed under the EVOLV project.",
|
"description": "Modular Node-RED package containing all control and automation nodes developed under the EVOLV project.",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"node-red",
|
"node-red",
|
||||||
@@ -28,7 +28,7 @@
|
|||||||
"dependencies": {
|
"dependencies": {
|
||||||
"@tensorflow/tfjs": "^4.22.0",
|
"@tensorflow/tfjs": "^4.22.0",
|
||||||
"@tensorflow/tfjs-node": "^4.22.0",
|
"@tensorflow/tfjs-node": "^4.22.0",
|
||||||
"generalFunctions": "git+https://gitea.centraal.wbd-rd.nl/RnD/generalFunctions.git#dev-Rene",
|
"generalFunctions": "file:../generalFunctions",
|
||||||
"mathjs": "^13.2.0"
|
"mathjs": "^13.2.0"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|||||||
Reference in New Issue
Block a user