Claus Ibsen created CAMEL-26720:
-----------------------------------
Summary: camel-chaos - chaos-add --dry-run and a check tool say
what a rule would hit, without adding it
Key: CAMEL-26720
URL: https://issues.apache.org/jira/browse/CAMEL-26720
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 4.24.0
The first part of S2-5 in the stage 2 order decided on CAMEL-26607: a check of
a rule before it is added, so a person or an AI that made a rule from a loose
request sees what it would do.
* {{camel cmd chaos-add --dry-run --rule=...}} checks the rules as chaos-add
would (a rule that is not valid is refused with the same reason) and adds
nothing.
* It prints each rule in plain words (ChaosRule.describe(), CAMEL-26717), then
what it would hit in the integration now: the sends to a matching endpoint with
their route and step, the sends known only when they send that may match (toD),
the polls, the routes of route=, the steps of step=, all narrowed by in=
(CAMEL-26718), and the warnings of a rule that matches nothing.
* {{ChaosManager.checkRules(String)}}, a {{check}} command of the chaos action
of the CLI connector, and the read-only tool {{camel_runtime_chaos_check}}
(MCP) / {{chaos_check}} (camel ask), in the chaos tool group.
* The check is read-only, so the read-only access level offers it and camel ask
does not ask first; it stays off the HTTP MCP tools of camel run --mcp, as the
integration parses the rule and exception= loads a class.
The eval set of loose prompts and the "describe the chaos you want" input of
the chaos screen come after.
_Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)