[Alerting v2] Split condition

[dominiqueclarke]

Summary

Related to #251326 (sets up condition clause that will be required for recovery)

ℹ️ This PR is built on top of #254995 and will be rebased when that PR is merged. It focuses on adding rule condition editing capabilities to the @kbn/alerting-v2-rule-form package.

This PR introduces condition editing for ES|QL alerting rules, allowing users to define WHERE clause conditions that determine when alerts should trigger.

Discover.-.Elastic.2.webm

Key Features

1. WHERE Clause Editor
A specialized Monaco-based editor for defining alert trigger conditions:

• Non-deletable | WHERE prefix for ES|QL syntax context
• Full ES|QL autocomplete with field suggestions from the base query
• Real-time syntax validation with inline error markers (squiggly lines)
• Semantic validation for field existence checking
• Debounced validation using useDebounceFn from @kbn/react-hooks

2. Query Splitting
Automatically separates an ES|QL query into base query and condition when the form initializes:

// Input: 'FROM logs-* | STATS count() BY host | WHERE count > 100'
// Output: { baseQuery: 'FROM logs-* | STATS count() BY host', condition: 'count > 100' }

This enables Discover to pass a full query, and the form will automatically extract the WHERE clause as the editable condition.

3. Condition Field Group
A new form section that displays:

• The base query (read-only when using DynamicRuleForm, editable when using StandaloneRuleForm)
• The WHERE clause condition editor

New Components

Component	Description
WhereClauseEditor	WHERE clause editor with ES
EvaluationQueryField	Pre-configured base query editor with validation
ConditionFieldGroup	Groups base query display + condition editor

New Hooks

Hook	Description
useQueryBaseAndCondition	Splits query into base + condition using AST parsing
useEsqlCallbacks	Creates ES

New Utilities

Utility	Description
splitQueryAndCondition	AST-based ES

Schema Changes

Files Changed

Area	Files	Description
Condition Editor	where_clause_editor.tsx	Monaco-based WHERE clause editor
Query Editor	esql_editor_field.tsx, evaluation_query_field.tsx	Base query editing
Field Group	condition_field_group.tsx	Condition section layout
Hooks	use_query_base_and_condition.ts, use_esql_callbacks.ts	Query parsing and ES
Utils	split_query_and_condition.ts	ES
Types	types.ts	Added condition to EvaluationQuery
Core Form	rule_form.tsx	Integrated ConditionFieldGroup
Form Defaults	use_form_defaults.ts	Uses query splitting for initial values
Discover	get_create_rule.tsx	Lazy loading to avoid Monaco issues in tests

How It Works

1. User opens rule form from Discover with query: FROM logs-* | STATS count() BY host | WHERE count > 100
2. useQueryBaseAndCondition parses the query and extracts:
   • Base query: FROM logs-* | STATS count() BY host
   • Condition: count > 100
3. Form displays base query as read-only and condition in the WhereClauseEditor
4. User can edit the condition with full autocomplete (fields, operators, functions)
5. On save, form combines: { base: "FROM logs-*...", condition: "count > 100" }

---

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• Monaco editor in tests: The WhereClauseEditor uses Monaco directly. Mitigated by mocking @kbn/code-editor in tests and lazy loading in Discover.
• Query splitting edge cases: AST-based splitting only extracts the last WHERE clause and only when it's the final command. Returns null gracefully for unsupported patterns.

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!
• Click to trigger kibana-deploy-cloud-from-pr for this PR!
• Click to trigger kibana-entity-store-performance-from-pr for this PR!
• Click to trigger kibana-storybooks-from-pr for this PR!