6a6c04d34b
- Update all submodule URLs from gitea.centraal.wbd-rd.nl to gitea.wbd-rd.nl - Add settler as proper submodule in .gitmodules - Add agent skills, function anchors, decisions, and improvements - Add Docker configuration and scripts - Add manuals and third_party docs - Update .gitignore with secrets and build artifacts - Remove stale .tgz build artifact Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
84 lines
4.2 KiB
Markdown
84 lines
4.2 KiB
Markdown
---
|
|
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)
|