Claus Ibsen created CAMEL-25143:
-----------------------------------
Summary: camel-jbang - TUI: AI project analysis that generates
route descriptions and an integration summary, shown as AI-assisted and exposed
via MCP and CLI
Key: CAMEL-25143
URL: https://issues.apache.org/jira/browse/CAMEL-25143
Project: Camel
Issue Type: New Feature
Components: camel-jbang
Reporter: Claus Ibsen
Give users a high-level, business-readable overview of a Camel project at the
source level: what each integration does, how the routes relate, and which
external systems they touch. Commercial iPaaS products offer this kind of
overview. Camel has the pieces (route topology, catalog metadata, TUI AI
panel), but nothing ties them together into an explained overview.
The main problem is that route diagrams turn into spaghetti in projects with
many routes, especially when routes have no {{description}}. An LLM can close
that gap: it can analyze the project once and produce the missing explanations.
Use the TUI as the prototype, as we already do for other AI features, and then
expose the same capability to agents and the CLI.
h3. Proposal
*1. AI project analysis (TUI setting)*
When an AI provider is configured in the TUI, add a setting (opt-in) that lets
the AI analyze the source/project and:
* propose {{description}} values for routes, and for key steps where they are
missing, applied as a normal source edit the user reviews and accepts, so the
result is versioned with the routes and benefits every tool (TUI, dev console,
diagrams, catalog)
* build an *integration summary file* for the project: capabilities / route
groups, entry points (HTTP, schedules, topics, files), external systems by
category, and the flows between routes (call / hand-off / event)
* refresh the summary when routes change (on demand, or when the source is out
of date with the summary)
*2. Show AI-assisted information distinctly*
Anything that comes from the AI (generated summaries, proposed descriptions not
yet accepted, explanations) must be shown in a dedicated color style or with a
hint marker, so end users learn to tell AI-assisted information apart from what
comes from the source code or the runtime.
*3. Layered overview instead of one flat diagram*
Use the summary to show capabilities / groups first (route {{group}},
file/folder layout, kamelets), and let the user drill down to routes and steps.
This keeps large projects readable.
*4. Explain relationships*
Let the user ask about edges, not just nodes: "why does intake hand off to
processing over seda?", "what happens if the Kafka topic is unavailable?".
Answer from the topology plus the summary (endpoints, link kinds, error
handlers).
*5. Flag structural issues*
The same analysis can point out orphan {{direct:}}/{{seda:}} endpoints, cycles,
routes with no description, and trivial pass-through routes.
*6. MCP tool and CLI*
Expose the analysis and the summary through the shared authoring tools (camel_
prefix, usable from both MCP servers) so any agent can use them, and through a
CLI command. The pre-generated summary is cheap to serve and works well with
small local models, because the heavy reasoning happened once.
h3. Notes
* Base component names and categories on the Camel catalog (titles and labels)
rather than hand-maintained lists, so all components are covered.
* Endpoint matching between routes should reuse the existing topology / URI
normalization (see the topology follow-up about components that need required
query parameters to match destinations).
* The summary file format should be plain and reviewable (e.g. Markdown or
YAML) and safe to commit. It must not include resolved property values or
secrets.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
