CancellationToken (#609), AutoExecuteActions (#596), additionalInputs example (#573)

[YogeshPraj]

Summary

Three Tier-4 feature requests that met the bar of being generic, well-justified, and implementable without breaking changes. Each is additive; default behavior is unchanged.

#609 — CancellationToken support on ExecuteAllRulesAsync

New overload ExecuteAllRulesAsync(string workflowName, RuleParameter[] ruleParams, CancellationToken cancellationToken). The token is observed cooperatively — checked between rules (ExecuteAllRuleByWorkflow) and before each action (ExecuteActionAsync). A single rule's compiled expression isn't interrupted mid-evaluation (they're fast synchronous delegates); cancellation happens at rule/action boundaries, which is where async action work lives.

Added to IRulesEngine as well, per the repo's Class_PublicMethods_ArePartOfInterface invariant. Source-compatible for all callers — the existing params object[] and params RuleParameter[] overloads are untouched; only someone who implements IRulesEngine themselves would need to add the member (the same is true of every prior API addition in this library).

#596 — ReSettings.AutoExecuteActions (default true)

When false, ExecuteAllRulesAsync evaluates rules but skips the automatic OnSuccess/OnFailure action execution, letting callers run actions selectively (the issue's use case: send only the first matched rule's decision to an external API) via ExecuteActionWorkflowAsync. Default true preserves current behavior exactly. Wired into the ReSettings copy constructor so it round-trips.

#573 — additionalInputs for EvaluateRule action (already supported; documented + tested)

EvaluateRuleAction already evaluates additionalInputs and adds them as rule parameters — the reporter just lacked a working example and hit "Unknown identifier". Added a test showing a computed input ("doubled" = input1.Value * 2) referenced by its Name in the target rule's expression. No code change; this lets the issue close with a concrete example.

Deferred (with reasons)

#	Request	Why not now
#623	Optional method parameters	System.Linq.Dynamic.Core method-resolution limitation; not fixable in RulesEngine without forking the parser
#598	Implicit property access on lists (Users.Name)	Non-standard semantics (not valid C# either); Users.Any(u => u.Name==…) already works
#565	SequentialAnd / SequentialOr operators	Already achievable: AndAlso/OrElse + NestedRuleExecutionMode.Performance short-circuits identically
#569	Multiple success/fail actions	Requires a workflow-schema change (OnSuccess → list); needs maintainer buy-in on API shape
#564	Access RulesEngine inside custom Action	Niche; reentrancy concerns; workaround = inject deps via custom action factory
#550	Bypass rule eval, run action only	Niche cross-process scenario, not generic

Test plan

• 3 new test files (Issue609Test, Issue596Test, Issue573Test) — 6 new tests covering happy path, cancellation (uncancelled + pre-cancelled), non-breaking signature checks, action-skip + selective-run, and the additionalInputs example.
• All 161 unit tests pass on net6.0 / net8.0 / net9.0 / net10.0.
• Class_PublicMethods_ArePartOfInterface passes (interface kept in sync).
• CHANGELOG [Unreleased] section updated.