RnD/EVOLV
3
0
Fork 0
Code Issues 22 Pull Requests Actions Packages Projects Releases Wiki Activity

rotatingMachine template + predicted-vs-measured composition rule #37

New Issue
Open
opened 2026-05-26 15:13:01 +00:00 by vps1_gitea_admin · 1 comment
vps1_gitea_admin commented 2026-05-26 15:13:01 +00:00
Owner
Copy Link

Type: slice

Depends on: #34, #35

Estimate: L (3 days)

Slice — layers touched

templates (rotatingMachine.json) → dashboardAPI domain (predicted/measured pair logic) → editor (folder structure) → integration test → example flow update.

Context

Implements PRD F-6 and F-7. Adds the second supported node type and the composition rule for paired predicted/measured panels.

Scope

  • Author src/templates/rotatingMachine.json with panels: %control, flow, Δp, efficiency. Each panel declares its emittedFields set (used by the no-data-duplication slice).
  • Composer detects when a rotatingMachine has a measurement child registered for the same quantity (e.g. flow) — render two side-by-side panels (predicted left, measured right) instead of one. If only predicted, one panel. If only measured, one panel.
  • Update one example flow to demo: rotatingMachine alone (predicted only), then add a measurement child (predicted+measured), redeploy, see new panel appear.

Out of scope

  • MGC and pumpingStation parent layouts — later slices.
  • Dashed bounds — later slice.

Acceptance criteria

  • rotatingMachine without measurement child → 4 panels (control/flow/Δp/efficiency), single column per metric.
  • Same rotatingMachine + measurement child for flow → flow panel becomes "predicted | measured" side-by-side; other 3 unchanged.
  • Integration test exercises both states.
**Type:** slice **Depends on:** #34, #35 **Estimate:** L (3 days) ## Slice — layers touched templates (`rotatingMachine.json`) → dashboardAPI domain (predicted/measured pair logic) → editor (folder structure) → integration test → example flow update. ## Context Implements PRD F-6 and F-7. Adds the second supported node type and the composition rule for paired predicted/measured panels. ## Scope - Author `src/templates/rotatingMachine.json` with panels: `%control`, `flow`, `Δp`, `efficiency`. Each panel declares its `emittedFields` set (used by the no-data-duplication slice). - Composer detects when a rotatingMachine has a `measurement` child registered for the same quantity (e.g. flow) — render two side-by-side panels (predicted left, measured right) instead of one. If only predicted, one panel. If only measured, one panel. - Update one example flow to demo: rotatingMachine alone (predicted only), then add a measurement child (predicted+measured), redeploy, see new panel appear. ## Out of scope - MGC and pumpingStation parent layouts — later slices. - Dashed bounds — later slice. ## Acceptance criteria - [ ] rotatingMachine without measurement child → 4 panels (control/flow/Δp/efficiency), single column per metric. - [ ] Same rotatingMachine + measurement child for flow → flow panel becomes "predicted | measured" side-by-side; other 3 unchanged. - [ ] Integration test exercises both states.
vps1_gitea_admin commented 2026-05-26 15:59:43 +00:00
Author
Owner
Copy Link

Slice #37 shipped on branch slice/37-rotatingmachine-template

Branches: dashboardAPI · EVOLV

Scope reduction — important architectural note

The existing config/machine.json template already covers the PRD F-6 panel set (state, mode, ctrl%, runtime, NCog%, flow predicted, efficiency, pressure up/down, temperature, prediction quality, confidence, drift, distance from peak) — 17 panels total, more than the PRD asked for.

The substantive new work was therefore narrower than the issue body implied:

  • ✅ Added meta.emittedFields annotation per panel in machine.json + machineGroup.json — needed by #39's parent dedup rule.
  • ✅ Added collectEmittedFields(dashboard) helper on the domain class.
  • ✅ Tests covering template-loading-with-annotations, aggregation, missing-meta graceful, null input.

Deferred: F-7 predicted-vs-measured side-by-side

The current architecture is "1 dashboard per node" (each child gets its own dashboard, cross-linked from the parent root dashboard). Side-by-side rendering of predicted (rotatingMachine dashboard) and measured (measurement child dashboard) on the SAME panel would require refactoring the composer from N-dashboards-per-flow to 1-dashboard-with-N-panels, plus composer-side awareness of registered measurement children and their ${measurement} substitution.

That's a v2 lift. The drill-down navigation (root → click child link → see measured values) covers the use case for now. Flag for revisit if the comparison UX matters more than the screen-space savings.

Closes #37.

## Slice #37 shipped on branch `slice/37-rotatingmachine-template` Branches: [`dashboardAPI`](https://gitea.wbd-rd.nl/RnD/dashboardAPI/src/branch/slice/37-rotatingmachine-template) · [`EVOLV`](https://gitea.wbd-rd.nl/RnD/EVOLV/src/branch/slice/37-rotatingmachine-template) ### Scope reduction — important architectural note The existing `config/machine.json` template **already covers** the PRD F-6 panel set (state, mode, ctrl%, runtime, NCog%, flow predicted, efficiency, pressure up/down, temperature, prediction quality, confidence, drift, distance from peak) — 17 panels total, more than the PRD asked for. The substantive new work was therefore narrower than the issue body implied: - ✅ Added `meta.emittedFields` annotation per panel in `machine.json` + `machineGroup.json` — needed by #39's parent dedup rule. - ✅ Added `collectEmittedFields(dashboard)` helper on the domain class. - ✅ Tests covering template-loading-with-annotations, aggregation, missing-meta graceful, null input. ### Deferred: F-7 predicted-vs-measured side-by-side The current architecture is "1 dashboard per node" (each child gets its own dashboard, cross-linked from the parent root dashboard). Side-by-side rendering of `predicted` (rotatingMachine dashboard) and `measured` (measurement child dashboard) on the SAME panel would require refactoring the composer from N-dashboards-per-flow to 1-dashboard-with-N-panels, plus composer-side awareness of registered measurement children and their `${measurement}` substitution. That's a v2 lift. The drill-down navigation (root → click child link → see measured values) covers the use case for now. Flag for revisit if the comparison UX matters more than the screen-space savings. Closes #37.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-architecture
Must-do structural/design changes for scaling
 P1-cleanup
Quick wins: remove deprecated code, fix inconsistencies
 P2-extensibility
Plugin architecture, output formats, config versioning
 P3-documentation
Docs, wiki, READMEs, architecture diagrams
 P4-testing
Test coverage, CI pipeline, integration tests
 bug
Confirmed bugs
 enhancement
New features / improvements
 security
Credentials, auth, vulnerabilities
 tech-debt
Code quality / cleanup
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lorenzo vps1_gitea_admin znetsixe
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RnD/EVOLV#37
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?