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

## Harness-Style Operating Rules
- Start from the live repo state, not generic playbooks.
- Build a file-level impact map before assigning specialist work.
- Define invariants first, then implement changes.
- Require evidence for each claim (tests, smoke checks, endpoint validation, or concrete diffs).
- Convert repeated lessons into updated skill guidance to reduce future ambiguity.

## Execution Flow
1. Frame the objective and constraints in one paragraph.
2. Build an impact map before assigning work. Identify touched contracts and files:
- `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. Declare invariants and acceptance criteria:
- backward compatibility posture: controlled breaks allowed only with migration
- safety posture: availability-first unless user overrides for a specific task
- security trust boundary/default behavior
- data schema/query compatibility where relevant
4. Route tasks to specialist skills with explicit deliverables and acceptance criteria.
5. Require each specialist to return:
- assumptions
- changed files
- tests added/updated
- unresolved risks
6. 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
7. Ask targeted user interview questions only at decision gates (see protocol below).
8. Produce a final integrated implementation with a risk log and decision log updates when needed.

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

Trigger an interview before finalizing when any of these are true:
- Breaking topic/payload/schema/API change is proposed
- Safety envelope or fail-safe defaults are loosened/tightened
- Security defaults or endpoint exposure changes
- Data retention/backfill/query behavior changes
- Rollout strategy has material operational risk

Default resolution rules when interviewing:
- prefer compatibility option with migration over undocumented hard breaks
- prefer availability-first behavior with explicit bounded safeguards
- always create/update a decision log entry for every decision-gate outcome

Question format:
- decision statement (one sentence)
- options with tradeoff
- recommended option and why

## Output Contract
Return:
- task breakdown by specialist
- execution order and dependencies
- measurable acceptance criteria
- integration risks and mitigation
- evidence summary (what was verified and how)
- decision log entries created/updated (if any)