WIKI_TEMPLATE.md — extend the canonical per-node page from 9 to 14 sections:
+ Header band (commit hash + regen date)
+ Code map (flowchart TB w/ subgraphs over concern modules)
+ Child registration (mirrors ChildRouter declarations)
+ Data model — getOutput() (abstract schema + optional concrete sample)
+ Debug recipes (symptom → first thing to check)
+ AUTOGEN markers around topic-contract + data-model schema so the
Phase 9 regen script can rewrite in place.
+ 'Picking a visual' table: Mermaid is default, plots/SVG/screenshots
allowed where they serve the data.
+ Archive banner snippet.
WIKI_HOME_TEMPLATE.md (new) — Home.md + Archive.md templates:
- Platform-wide Mermaid graph of 11 active nodes, S88-coloured.
- Navigation table grouped by S88 level.
- Standards-pointer table to .claude/rules + .claude/refactor docs.
- Live refactor-status table for returning visitors.
- Archive index template with archival-date column.
No wiki pages written yet — next step is one worked example
(pumpingStation) before any change to the Gitea wiki repo.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EVOLV Platform Refactor — Guidelines
This directory holds the durable plan and conventions for the platform-wide refactor of the EVOLV Node-RED nodes. Anyone (human or agent) working on this refactor reads these files first.
Goals
- Eliminate boilerplate — every nodeClass today is ~80% identical.
Move the shared parts into
generalFunctions/. Each node keeps only what is genuinely node-specific. - Split big domain classes —
pumpingStation,machineGroupControl, androtatingMachineeach have ~1000–1800 line monolithicspecificClass.jsfiles mixing 6+ concerns. Split each into focused concern-based modules undersrc/. - Document the contract — every msg.topic the node accepts and every
message it emits is declared in code (a
commands/module) and surfaced in a per-nodeCONTRACT.md. - Standardise naming — consistent topic names across the platform
(
set.<noun>,cmd.<verb>,evt.<noun>). - Keep it readable — small files, small functions, comments that say why and skip what.
Constraint: this is the development branch
All 12 submodules + the parent EVOLV repo are on a development branch.
main is untouched. We can change anything without breaking deployments
that track main.
The refactor lands on development. Promotion to main happens once the
whole platform passes its 3-tier tests + Docker E2E.
Layered approach
The refactor is sequenced as tiers, not a big bang.
| Tier | What | Risk | Reversible? |
|---|---|---|---|
| 1 | Add infra in generalFunctions (additive only — no breaking changes) |
Low | Yes |
| 2 | Pilot one node (pumpingStation) end-to-end on the new infra | Med | Yes |
| 3 | Convert remaining core nodes (measurement, MGC, rotatingMachine) | Med | Yes |
| 4 | Convert remaining nodes (valve, VGC, reactor, settler, monster, diffuser, dashboardAPI) | Low | Yes |
| 5 | Standardise input topic names + deprecation map | Med | Behind feature flag |
| 6 | Promote development → main once Docker E2E green platform-wide |
Low | Yes |
| 7 | Wiki cleanup — visual-first template + Mermaid diagrams per node (post-refactor) | Low | Yes |
Each tier is a sequence of small PRs on development, each with its
existing tests green.
Files in this directory
| File | Purpose |
|---|---|
README.md |
This file. |
CONVENTIONS.md |
Code style, file size, comments, naming, imports, tests. |
CONTRACTS.md |
The exact shapes — BaseNodeAdapter, BaseDomain, commands registry, child router, unit policy, status badge, output ports. |
MODULE_SPLIT.md |
Per-node src/ layout for the 4 core nodes + a generic template. |
TASKS.md |
Phased task list. The TaskCreate task tree mirrors this and is the active tracker. |
OPEN_QUESTIONS.md |
Decisions deferred to later — collected here so we don't lose them. |
Workflow rules for spawned agents
If you are an agent working on a refactor task:
- Read this file,
CONVENTIONS.md,CONTRACTS.md, and the relevant section ofMODULE_SPLIT.mdbefore changing code. - Stay within the scope of one task. Don't expand scope without flagging.
- Run the affected node's tests after every meaningful change. Commands:
cd nodes/<nodeName> && node --test test/basic test/integration test/edge - Don't change
generalFunctionsexports unless your task is in tier 1. - If you discover something unclear, append it to
OPEN_QUESTIONS.mdwith a short note. Do not invent a decision. - Comments: small, function-level, why not what. See
CONVENTIONS.md. - When done, summarise: files changed, tests run, anything deferred to
OPEN_QUESTIONS.md.