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>
63 lines
2.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
---
|
|
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.
|
|
|
|
## Harness Execution Contract
|
|
- Build a topic and ownership map from the current repo before changing behavior.
|
|
- Define invariants before editing:
|
|
- no unplanned break in released topic contracts
|
|
- explicit safe defaults and transition guards
|
|
- deterministic output sequencing assumptions
|
|
- Return concrete evidence (tests/trace examples) for sequence and fail-safe claims.
|
|
|
|
## 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
|
|
|
|
Decision interview triggers:
|
|
- any topic rename/removal or payload schema break
|
|
- authority changes across parent/child nodes
|
|
- startup/shutdown sequencing changes with operational impact
|