Davis Plumlee

Deployment links have been added to the PR in the [latest build message](https://github.com/elastic/kibana/pull/179680#issuecomment-2033427825) for acceptance and exploratory testing. cc @vgomez-el @approksiu

All of our logic changes are now (hopefully) complete and the tickets/acceptance criteria have been updated to match. The new deployment links should be added to the latest build message....

The latest deployment links are in the most [recent build message](https://github.com/elastic/kibana/pull/179680#issuecomment-2078523617). Would appreciate some eyes for acceptance/exploratory testing when everyone has a chance, thanks! cc: @vgomez-el @approksiu @ARWNightingale

@banderror This has been fixed in the most recent build, a leftover remnant from refactoring logic. > Secondly, in the AC we have: > > > On the rule edit...

@ARWNightingale @vgomez-el Any update on acceptance/exploratory testing for this component? Hoping to merge before the next serverless branch on monday.

How do we feel about selecting the name for `max_signals` to be "Max signals"? Obviously that's the field name but seeing as this is the first time ([other than maybe...

@joepeeples yeah, we can't easily rename the field without a lot of problems but in the one prior example we have of referring to the value in the UI, we...

/ci

@jpdjere you are correct in thinking that `xpack.alerting.rules.run.alerts.max` is a "hard maximum" in terms of alert writing and will overwrite our `max_signals` value in terms of a limit. For instance...

The one thing I could see us doing instead is defaulting `max_signals` to 100 _unless_ `xpack.alerting.rules.run.alerts.max` is less than 100 - then we default to whatever the config value is...