[
https://issues.apache.org/jira/browse/CAMEL-26760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141059#comment-18141059
]
Claus Ibsen commented on CAMEL-26760:
-------------------------------------
Decisions (with Claus, 2026-11-09):
* *CLI:* {{camel cmd chaos-explore --budget=10m}} is added, using the AI of
camel ask, so scripts, CI and other agents can call it. {{camel ask "let there
be chaos"}} and the TUI key run the same playbook.
* *Journal:* in camel-chaos ({{ChaosManager}}), with the deadline. The TUI,
{{camel get chaos}} and the report read it, it survives the agent losing
context, and camel-chaos enforces the budget.
* *Combinations:* {{chaos-suggest}} also lists pairs of faults worth trying
together (an outage while the DLC fails, a slow call and a timeout, a hand-off
and a failing next route). The model picks from them, and may add its own with
budget left.
* *Budget:* 10 minutes by default, 2 hours at most. Rules are capped to the
deadline.
* *Files:* everything under {{test/chaos}} (CAMEL-26761): scenarios
{{test/chaos/<name>.chaos}}, the feed of a scenario in the folder of the same
name next to it ({{001.json}}, optional {{001.properties}} headers) with a
{{feed=<endpoint> interval=}} line in the scenario, and reports in
{{test/chaos/reports/}}.
_Claude Code on behalf of Claus Ibsen_
> camel-chaos - stage 3: let there be chaos, an AI agent explores chaos rules
> on a project by itself and reports back
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26760
> URL: https://issues.apache.org/jira/browse/CAMEL-26760
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> The user tells an AI agent "let there be chaos" on a Camel project. Within a
> time budget, the agent runs the project, tries chaos rules by itself, sends
> traffic, reads the report, errors and log, and comes back with a report: what
> it tried, what held, what broke, and scenarios to replay.
> Most of the pieces are on main from stage 1 and 2 (CAMEL-26330, CAMEL-26607):
> chaos suggest and the tried table (what to try), chaos check (safe to add),
> expectations (a verdict that does not depend on the model), scenarios with a
> seed (replay and CI gate), and the MCP tools. The agent that wrote the chaos
> example already did this by hand, and found CAMEL-26734. This ticket makes it
> a feature.
> h3. What is missing
> # *A playbook.* An MCP prompt {{camel_chaos_explore}} (budget, focus, traffic
> allowed) next to the prompts in {{PromptDefinitions}}, with the same text
> behind {{camel ask}} and a key on the TUI chaos screen. Loop: baseline
> without rules (errors already there are not blamed on chaos), suggest, pick a
> kind not tried, state the expectation, check, add with a short until=, send
> traffic, wait for the verdict, read, clear, next. Single faults first, then
> pairs ("two failures meet").
> # *Traffic.* Timer routes feed themselves, platform-http can be fed with
> curl, but Kafka, JMS, AMQP etc. cannot. Stage 1: run with {{--stub=remote}}
> by default and feed the stubbed consumers with {{camel cmd send}}, which
> needs {{--repeat}} / {{--interval}} (today it sends one message), also on
> {{camel_runtime_send}}. The suggestions say per route how to feed it. Stubbed
> messages are not real Kafka, but close enough to test the error handling.
> # *Safety.* The faults are local, the traffic is not: by default remote
> endpoints are stubbed, and the agent asks before it sends to anything real.
> One consent covers the whole budget, instead of a confirm per rule.
> camel-chaos enforces the deadline: rules are capped to the end of the
> exploration, and cleared when it ends. The agent never edits the routes:
> hints only.
> # *One experiment per call.* {{chaos_experiment}} (rule(s), traffic, max
> wait) returns a compact result when the expectations are decided: verdict,
> per route delta, new errors, faults fired. About 10 large calls instead of
> 100 small ones, which matters for small local models.
> # *A journal and a report.* camel-chaos keeps a journal of the exploration:
> baseline, each experiment with its hypothesis, rules, seed and outcome. The
> report is text for the CLI, JSON for tools and markdown in
> {{chaos/report-<time>.md}}. Each finding is classified (route gap: no
> breaker, no DLC, not idempotent, hand-off loses; or suspected Camel bug),
> with evidence and a hint, and experiments worth keeping are saved as
> {{chaos/explore-*.chaos}} scenarios.
> # *TUI.* An Explore mode on the chaos screen: budget dialog, the experiments
> live, and the report at the end.
> h3. Stage 2 (later)
> * Realistic traffic with Citrus ({{camel test run}}): real brokers through
> test-infra, message shapes from a schema or samples.
> * A non-AI explore ({{--no-ai}}): the top suggestions in order, each with its
> own expectation and traffic, for CI and as a floor for small models.
> * Several integrations at once (a hand-off over a real broker).
> h3. Open questions
> * Do chaos rules on {{endpoint=kafka:...}} match the stubbed endpoint, and
> does {{camel cmd send}} to a stubbed consumer feed it? To verify first.
> * CLI shape: {{camel cmd chaos-explore --budget=10m}} (uses the AI of camel
> ask) or only {{camel ask "let there be chaos"}}.
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
