[davsclaus]

Stacked on #28178 (CAMEL-25750), which keeps the body types each step of a route has been reached with, across the messages, with their kinds: null, payload, data and collection. This brings them to the Routes and Diagram views of camel tui, as sketched in CAMEL-25892.

The route in the screenshots unmarshals JSON, and only one branch of a choice marshals it again. The step after the choice is then reached with a stream from some messages and a map from others. That step needs attention: a step that writes the body fails for the map, one that reads fields fails for the stream.

camel-diagram

• The node of a route diagram keeps the body types and kinds of its step (NodeInfo.bodyTypes / bodyKinds). RouteDiagramHelper reads them from the route-structure JSON, and the steps of an onException block copied into the error frame keep them. Any renderer can draw them from there.

Diagram view

• y shows the types beside the arrow into each step, on the shaft above the arrowhead. Where a branch bends right above the head, they go after the message count there. The arrows then show how the body changes along the route.
• A label gets as much room as there is before the next box, arrow or marker. When it does not fit, it is shortened in this order:
  • all the types with their kinds;
  • all the types;
  • the first ones and how many more, such as ⚠ ByteArrayInputStreamCache +2;
  • the first one cut.
• A step reached with bodies of more than one kind has a ⚠ in its top border, also with y off.
• The Info panel of a step lists all its types with their kind, and says why mixed kinds need attention. In the topology, the Info panel of a route shows its counts, such as Body: ⚠ 4 mixed.
• tui_get_state gives the bodyTypes and bodyKinds of the selected step, so an AI client sees them too.
• While the types are shown, they follow the status file the way the metrics do: a type seen for the first time shows up at the next refresh.

Routes view

• The routes table has a BODY TYPES column when a route has steps that varied: how many varied, and how many of them with bodies of more than one kind (⚠ 1 mixed · 2 varied).
• The processors of the selected route have the types of each step.

Other

• DiagramSupport was at the size limit of SourceSizeTest. Its three layout helpers moved to DiagramLayouts, unchanged, and the two Info panel methods are now under the method limit.
• Docs: the help pages of the Diagram and Routes tabs, and a Body Types section in the manual's diagram page with these screenshots.

Tests

• camel-diagram: RouteDiagramHelperTest and RouteErrorFrameTest.
• TUI:
  • BodyTypesOnArrowsTest draws a route into a buffer: the labels on the shafts, a label cut beside the arrows of a branch, and the ⚠ mark with the labels off.
  • BodyTypesViewsTest covers the label fitting, the Info panel lines and the Routes columns.
  • DiagramTopologyTest covers the live types from the status file, and AbstractDiagramTabTest the y key in both tabs.
  • The 2194 tests of the module pass.
• Checked live in a scratch camel tui, against an integration that runs on the jars of this branch; the screenshots are from that session.

Not in this PR: the Source view of the issue, which needs CAMEL-25771, and Shift+F8 from the diagram.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet-bot]

Well-structured feature PR with thorough test coverage. ✅

• All NodeInfo copy paths propagate the new fields correctly
• Backward compatibility is handled (existing callers unaffected)
• The label-fitting logic has correct boundary conditions
• Minor: RouteDiagramHelper.strings() silently drops null elements while StatusParser.stringList() converts them to the string "null" via String.valueOf(). Academic given the real data flow, but worth keeping in mind if these helpers are ever reused in other contexts.

This review was generated by an AI agent, Hermès on behalf of @gnodet.