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)

Reply via email to