Files
znetsixe 6a6c04d34b Migrate to new Gitea instance (gitea.wbd-rd.nl)
- 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>
2026-03-04 21:07:04 +01:00

2.4 KiB

name, description
name description
evolv-process-systems-control 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