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>

.agents/decisions/DECISION-20260216-agent-harness-defaults.md

@@ -0,0 +1,38 @@
+# DECISION-20260216-agent-harness-defaults
+
+## Context
+- Task/request: Adapt EVOLV agents/skills using Harness Engineering patterns and set owner-controlled operating defaults.
+- Impacted files/contracts: `AGENTS.md`, `.agents/skills/*/SKILL.md`, `.agents/skills/*/agents/openai.yaml`, decision-log policy.
+- Why a decision is required now: New harness workflow needs explicit defaults for compatibility, safety bias, and governance discipline.
+
+## Options
+1. Compatibility posture
+- Option A: strict backward compatibility
+- Option B: controlled compatibility breaks with migration notes
+
+2. Safety posture
+- Option A: protection-first
+- Option B: availability-first
+
+3. Decision logging scope
+- Option A: required only for breaking/risky changes
+- Option B: required for all decision-gate outcomes
+
+## Decision
+- Selected option: Compatibility `controlled`; Safety `availability-first`; Decision logging `required for all decision-gate changes`.
+- Decision owner: User
+- Date: February 16, 2026
+- Rationale: Maintain delivery and operational continuity while preserving governance through mandatory, durable decision records.
+
+## Consequences
+- Compatibility impact: Breaking contract changes are permissible only when migration/deprecation is explicit.
+- Safety/security impact: Control changes should bias toward continuity with bounded safeguards; critical protections still require explicit constraints.
+- Data/operations impact: Decision traceability improves cross-turn consistency and auditability.
+
+## Implementation Notes
+- Required code/doc updates: Set defaults in `AGENTS.md` and orchestrator skill instructions; keep decision-log template active.
+- Validation evidence required: Presence of defaults in policy docs and this decision artifact under `.agents/decisions/`.
+
+## Rollback / Migration
+- Rollback strategy: Update defaults in `AGENTS.md` and orchestrator SKILL; create a superseding decision log entry.
+- Migration/deprecation plan: For any future hard-break preference, require explicit migration plan and effective date in a new decision entry.

.agents/decisions/DECISION-20260223-pid-controller-placement-and-flowbased.md

@@ -0,0 +1,43 @@
+# Decision: Shared Modern PID in generalFunctions + PumpingStation Flow-Based Adoption
+
+- Date: 2026-02-23
+- Scope: `nodes/generalFunctions/src/pid/*`, `nodes/pumpingStation/src/*`
+
+## Context
+Flow-based control in `pumpingStation` needed a production-grade PID with freeze/unfreeze, runtime retuning, and support for cascade/secondary-loop architecture.
+
+## Options Considered
+1. Implement PID only inside `pumpingStation`.
+2. Implement shared PID in `generalFunctions` and consume it from `pumpingStation`.
+3. Keep current heuristic (non-PID) flow controller.
+
+## Decision
+Chose option 2.
+
+## Rationale
+- PID behavior is cross-domain control functionality and should be reusable across EVOLV nodes.
+- `generalFunctions` already serves as shared utility/runtime infrastructure.
+- Reuse reduces drift and duplicated control logic.
+- PumpingStation can immediately adopt shared PID while preserving existing topic contracts.
+
+## Consequences
+- Positive:
+  - Single, test-covered PID implementation with modern features.
+  - PumpingStation flow mode becomes true closed-loop control.
+  - Runtime support for freeze/unfreeze and tuning updates without redeploy.
+- Risks:
+  - Behavioral differences versus prior heuristic flow control.
+  - Requires conservative tuning per site.
+
+## Safety / Compatibility
+- No existing topic names were removed.
+- Added optional control topics for PID runtime management.
+- Existing non-flowbased modes remain intact.
+
+## Rollback
+- Revert `nodes/pumpingStation/src/specificClass.js` flow-based branch to previous heuristic logic.
+- Keep shared PID module in `generalFunctions` for future use, or revert `nodes/generalFunctions/src/pid/*` if required.
+
+## Migration Notes
+- For `flowbased`, start with low `kp/ki`, verify stability in commissioning, then tune upward.
+- Use `freezeFlowPid` and `setFlowPidMode` during maintenance or manual takeover.

.agents/decisions/DECISION-20260224-nrmse-hardening-and-metric-profiles.md

@@ -0,0 +1,33 @@
+# Decision: Harden NRMSE and Use Metric Profiles in RotatingMachine
+
+- Date: 2026-02-24
+- Scope: `nodes/generalFunctions/src/nrmse/*`, `nodes/rotatingMachine/src/specificClass.js`
+
+## Context
+Drift analytics were previously single-path and flow-focused with weak input safeguards in NRMSE.  
+Requirement: make NRMSE architecturally robust and apply it across multiple measurements in rotatingMachine.
+
+## Decision
+Adopt a metric-profile drift architecture:
+
+1. Harden `generalFunctions/nrmse` with:
+- strict validation for malformed inputs
+- timestamp-aware alignment support
+- per-metric state
+- configurable rolling window and EWMA long-term trend
+- point-based API (`assessPoint`) while retaining legacy calls
+
+2. Rewire rotatingMachine to consume NRMSE per metric:
+- `flow` model drift
+- `power` model drift
+- pressure-quality drift as node-specific plausibility/redundancy assessment
+
+3. Expose drift and confidence outputs per metric in node output payload.
+
+## Consequences
+- Drift computations are deterministic and safer under bad inputs.
+- RotatingMachine confidence now reflects multiple measurement channels.
+- Output schema expands with power/pressure drift fields.
+
+## Rollback Notes
+- Revert `errorMetrics.js` and rotatingMachine drift wiring to return to legacy flow-only drift behavior.

.agents/decisions/DECISION-20260224-rotatingmachine-hydraulic-efficiency-and-confidence.md

@@ -0,0 +1,34 @@
+# Decision: RotatingMachine Hydraulic Efficiency Correction and Prediction Confidence
+
+- Date: 2026-02-24
+- Scope: `nodes/rotatingMachine/src/specificClass.js`, rotatingMachine integration tests
+
+## Context
+Hydraulic efficiency calculation in `rotatingMachine` was dimensionally inconsistent and could over/under-report efficiency KPIs.  
+At the same time, prediction drift tooling (`nrmse`) existed but was not actively connected to rotatingMachine output confidence.
+
+## Options Considered
+1. Keep existing formula and only tune thresholds.
+2. Replace formula with standard hydraulic power/efficiency equations and expose prediction confidence from live pressure source + drift.
+
+## Decision
+Adopt option 2.
+
+- Hydraulic power now follows standard engineering relation:
+  - `P_h = Q * Δp` (equivalent to `ρ g Q H`)
+  - `η_h = P_h / P_in`
+- RotatingMachine now computes flow drift via `nrmse` from measured vs predicted flow windows.
+- RotatingMachine now exposes prediction confidence fields in output:
+  - `predictionQuality`
+  - `predictionConfidence`
+  - `predictionPressureSource`
+  - `predictionFlags`
+
+## Consequences
+- Efficiency KPIs become physically interpretable and traceable to pressure/flow/power inputs.
+- Prediction trust is now observable by downstream control/dashboard layers.
+- Output schema is expanded with new prediction confidence fields.
+
+## Rollback / Migration Notes
+- Rollback path: revert `specificClass.js` hydraulic block and prediction-health integration.
+- No mandatory migration required for existing flows unless they choose to consume new prediction confidence fields.

.agents/decisions/DECISION-20260224-rotatingmachine-unit-anchor-and-curve-normalization.md

@@ -0,0 +1,38 @@
+# Decision: Canonical Unit Anchoring and Curve Unit Normalization in RotatingMachine
+
+- Date: 2026-02-24
+- Scope: `nodes/rotatingMachine/*`, `nodes/generalFunctions/src/measurements/MeasurementContainer.js`, `nodes/generalFunctions/src/configs/rotatingMachine.json`
+
+## Context
+RotatingMachine previously relied on node-local defaults for measurement storage units, with implicit assumptions that loaded machine curves used the same units as runtime configuration. This made unit drift likely when model curves, simulated inputs, and runtime settings differed.
+
+Owner decision direction:
+- use a single unit anchor strategy
+- treat node/UI units as ingress/egress only
+- add explicit curve unit metadata
+- reject or flag blank/invalid measurement units
+
+## Decision
+1. Extend `MeasurementContainer` with optional canonical-anchor mode:
+- per-type canonical unit mapping
+- strict unit validation and required-unit policy
+- compatibility checks by measure family
+- requested-unit conversion at flattened output stage
+
+2. Apply canonical policy in `rotatingMachine` runtime:
+- internal storage and calculations anchored to SI-like canonical units (`Pa`, `m3/s`, `W`, `K`)
+- egress payloads converted back to configured output units
+- ingress `simulateMeasurement` path requires explicit valid units
+
+3. Add explicit curve unit metadata (`asset.curveUnits`) and normalize loaded curves into canonical units before predictor initialization.
+
+## Consequences
+- Unit handling is centralized and deterministic for RotatingMachine.
+- Curve/model-unit mismatch risk is reduced by explicit metadata plus normalization.
+- Existing output topic/field names remain stable; values are emitted in configured output units while internals stay canonical.
+- This establishes a migration template for remaining EVOLV nodes.
+
+## Rollback Notes
+- Revert `MeasurementContainer` canonical/validation extensions.
+- Revert RotatingMachine unit-policy and curve-normalization wiring.
+- Remove `asset.curveUnits` schema entry and restore previous node-local default-unit behavior.

.agents/decisions/DECISION-20260224-unit-anchor-rollout-phase1-machinegroup-pumping-valves.md

@@ -0,0 +1,37 @@
+# Decision: Unit-Anchor Rollout Phase 1 (MachineGroup, PumpingStation, Valve, ValveGroupControl)
+
+- Date: 2026-02-24
+- Scope:
+  - `nodes/machineGroupControl/src/nodeClass.js`
+  - `nodes/machineGroupControl/src/specificClass.js`
+  - `nodes/pumpingStation/src/nodeClass.js`
+  - `nodes/pumpingStation/src/specificClass.js`
+  - `nodes/valve/src/nodeClass.js`
+  - `nodes/valve/src/specificClass.js`
+  - `nodes/valveGroupControl/src/nodeClass.js`
+  - `nodes/valveGroupControl/src/specificClass.js`
+
+## Context
+After adopting canonical-unit anchoring in `rotatingMachine`, adjacent controller nodes still mixed local units, unitless writes, and implicit conversions. That left cross-node behavior sensitive to registration order and source-unit assumptions.
+
+## Decision
+1. Apply the same canonical storage policy per node:
+- internal storage in canonical units (`Pa`, `m3/s`, `W`, `K` where relevant),
+- preferred/output units for operator-facing status and output payloads.
+
+2. Enable strict measurement ingress discipline on migrated nodes:
+- `strictUnitValidation: true`,
+- `throwOnInvalidUnit: true`,
+- required unit for physically dimensional types (`flow`, `pressure`, `power`, `temperature`, and node-specific equivalents).
+
+3. Replace unitless runtime writes/reads with explicit-unit helpers in each node’s domain class, including child-machine/child-valve interactions.
+
+## Consequences
+- Cross-node calculations now run against a deterministic unit anchor in phase-1 nodes.
+- Status/output values remain in preferred/output units, while internal math stays canonical.
+- Legacy paths that send dimensional values without units now fail fast instead of silently coercing.
+
+## Rollback Notes
+- Revert the eight files listed in scope.
+- Restore previous `MeasurementContainer` initialization (non-canonical, non-strict behavior) in each node.
+- Remove helper-based explicit unit reads/writes and revert to prior direct chain usage.

.agents/decisions/DECISION_TEMPLATE.md

@@ -0,0 +1,36 @@
+# DECISION-YYYYMMDD-<slug>
+
+## Context
+- Task/request:
+- Impacted files/contracts:
+- Why a decision is required now:
+
+## Options
+1. Option A
+- Benefits:
+- Risks:
+- Rollout notes:
+
+2. Option B
+- Benefits:
+- Risks:
+- Rollout notes:
+
+## Decision
+- Selected option:
+- Decision owner:
+- Date:
+- Rationale:
+
+## Consequences
+- Compatibility impact:
+- Safety/security impact:
+- Data/operations impact:
+
+## Implementation Notes
+- Required code/doc updates:
+- Validation evidence required:
+
+## Rollback / Migration
+- Rollback strategy:
+- Migration/deprecation plan:

.agents/decisions/README.md

@@ -0,0 +1,15 @@
+# EVOLV Decision Log
+
+Use this folder to store high-impact agent/user decisions that affect compatibility, safety, security, schema, or rollout risk.
+
+Naming:
+- `DECISION-YYYYMMDD-<slug>.md`
+
+When to log:
+- topic/payload/API contract changes
+- safety envelope or fail-safe strategy changes
+- security posture/default changes
+- Influx retention/backfill/schema tradeoffs
+- explicit acceptance of deferred high-risk debt
+
+Start from `DECISION_TEMPLATE.md` for new entries.