[
https://issues.apache.org/jira/browse/CAMEL-25143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120896#comment-18120896
]
Claus Ibsen commented on CAMEL-25143:
-------------------------------------
Pull request: https://github.com/apache/camel/pull/27103 (CAMEL-25143 and
CAMEL-25147 in one squashed commit).
_Claude Code on behalf of davsclaus_
> 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
> Assignee: Claus Ibsen
> Priority: Major
>
> 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)
