## Summary

> [!NOTE]
> Dear reviewers. This PR is getting merged into a feature branch. Only
the ResponseOps review is needed it at the moment. We will request for
your review when we open the feature branch PR to be merged on `main`.

This PR implements the Director component of the alerting v2 core
engine. The Director is an asynchronous state engine responsible for
deriving alert state transitions (e.g., Pending → Active) from the
immutable stream of raw alert events.

## Architecture

### Strategy Pattern
To ensure the Director remains agnostic of specific business logic, we
implemented the Strategy Pattern. The Director facilitates the data
flow, while an `ITransitionStrategy` defines the actual state machine
logic. This allows us to support different transition behaviors, based
on rule configuration or alert event type, without modifying the core
service. It may seem overengineering at the moment, but I think it will
help us in the long run. At the moment, only one strategy is supported,
the `BasicTransitionStrategy`, which moves the states like `inactive ->
pending -> active -> recovering -> inactive` based on a) the status of
the alert event and the latest episode status if exist.

### Episode Lifecycle Management

The state is calculated as:

- **Inactive + Breached → `Pending`**: A new alert has started, but must
wait in Pending before becoming Active.
- **Pending + Recoverde → `Inactive`**: The condition cleared before it
could become Active.
- **Active + Recovered → `Recovering`**: An active alert has stopped
breaching and enters the recovery phase.
- **Recovering + Breached → `Active`**: An alert that was recovering has
breached again.

The episode ID is preserved across pending, active, and recovering
states. A new episode ID is generated only when transitioning from
inactive to a non-inactive state (a new episode starts).

> [!IMPORTANT]  
> Calculating the states based on counts or timeframes will be
implemented on the next PR to avoid growing the size of the PR and make
reviewing the fundamentals of the director easier. Same for streaming
the ESQL results to the director and to the datastream.

```mermaid
flowchart LR
    subgraph Lifecycle["Episode Lifecycle"]
        direction LR
        
        INACTIVE((INACTIVE))
        PENDING((PENDING))
        ACTIVE((ACTIVE))
        RECOVERING((RECOVERING))
        
        INACTIVE -->|"breached<br/>New Episode ID"| PENDING
        PENDING -->|breached| ACTIVE
        ACTIVE -->|recovered| RECOVERING
        RECOVERING -->|recovered| INACTIVE
        
        RECOVERING -->|"breached<br/>"| ACTIVE
        PENDING -->|"recovered<br/>Episode Ends"| INACTIVE
    end

    style INACTIVE fill:#9e9e9e,color:#fff
    style PENDING fill:#ffc107,color:#000
    style ACTIVE fill:#f44336,color:#fff
    style RECOVERING fill:#ff9800,color:#000
```

### Example

**Alert events**

Row | @timestamp | Status | Episode status | Episode ID
-- | -- | -- | -- | --
1 | 10:00 | breached | pending | uuid-1
2 | 10:05 | breached | active | uuid-1
3 | 10:10 | recovered | recovering | uuid-1
4 | 10:15 | recovered | recovered | uuid-1
5 | 10:20 | breached | pending | uuid-2

### Out of scope

- Changed state transitions based on counts or timeframes.
- Streaming of ES|QL results

## Testing
1. Create a rule that fires breach events.

2. Maturation:
- Verify that the alert event documents have the correct episode status,
alert event status, and the episode ID on each run.
    
Recovering is not possible to be tested atm as we need the rule executor
to produce these alert events.

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

elastic#251529)

resolves elastic/rna-program#106

## Summary

Use QueryService in Dispatcher, and update query to use latest
alert-event mapping (episode.id, episode.status). Updated integration
tests accordingly.

## Summary

Refactors task registration to use a declarative binding pattern similar
to route registration, making it easier to add new task types.

**Changes:**
- Add `TaskDefinition` token and `AlertingTaskDefinition` interface for
task definitions
- Replace `registerRuleExecutorTaskDefinition()` function with
`RuleExecutorTaskDefinition` constant object
- Create `bind_tasks.ts` with `onActivation` hook for automatic Task
Manager registration
- Add `requiresFakeRequest` option to `TaskRunnerFactory` to support
tasks that don't need API key authentication

### Before

```typescript
// Manual registration in bind_on_setup.ts
registerRuleExecutorTaskDefinition({
  taskManager: container.get(PluginSetup('taskManager')),
  taskRunnerFactory: container.get(TaskRunnerFactoryToken),
});
```

### After

```typescript
// Declarative binding in bind_tasks.ts
bind(TaskDefinition).toConstantValue(RuleExecutorTaskDefinition);
// Registration happens automatically via onActivation
```

### Adding new task types

```typescript
// 1. Define the task
export const MyTaskDefinition: AlertingTaskDefinition<MyTaskRunner> = {
  taskType: 'alerting_v2:my_task',
  title: 'My Task',
  timeout: '5m',
  paramsSchema: schema.object({ /* ... */ }),
  taskRunnerClass: MyTaskRunner,
  requiresFakeRequest: false, // optional, defaults to true
};

// 2. Bind it
bind(TaskDefinition).toConstantValue(MyTaskDefinition);
```

## Summary

This PR skips running the director if the rule is not alertable.

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

## Summary

Closes elastic/rna-program#124

This PR creates a `UserService` class to abstract the internals of the
security plugin when accessing user information.

Usages of `username` were replaced by `profile_uid`.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…tion_tests/ci_checks

…ic#252073)

## Summary

**I am opening this for review, but I am still running some manual
tests.**

Closes elastic/rna-program#121

This PR changes the resource initializer in `alerting_v2` to use the
`@kbn/data-streams` package.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Resolves elastic/rna-program#84


## Summary


> [!NOTE]
> I've followed the same approach as the rules API / Rules Client /
Rules Saved Object

This PR introduces the Notification Policy saved object, the CRUD APIs
and a client to use from the API and other services.
Added Integration tests on top of uni tests



## Manual testing

```bash
curl --request POST \
  --url http://localhost:5601/internal/alerting/v2/notification_policies \
  --header 'Authorization: Basic <token>' \
  --header 'Content-Type: application/json' \
  --header 'kbn-xsrf: true' \
  --header 'x-elastic-internal-origin: kibana' \
  --data '{  "name": "policy-1",  "description": "desc", "workflow_id": "my-workflow-id"   }'

# note <<ID>>

curl --request GET \
  --url http://localhost:5601/internal/alerting/v2/notification_policies/<ID> \
  --header 'Authorization: Basic <token>' \
  --header 'Content-Type: application/json' \
  --header 'kbn-xsrf: true' \
  --header 'x-elastic-internal-origin: kibana'


curl --request PUT \
  --url http://localhost:5601/internal/alerting/v2/notification_policies/<ID> \
  --header 'Authorization: Basic <token>' \
  --header 'Content-Type: application/json' \
  --header 'kbn-xsrf: true' \
  --header 'x-elastic-internal-origin: kibana' \
  --data '{   "name": "policy-1-updated", "description": "desc", "workflow_id": "my-workflow-id-2", "version": "doc_version"   }'


curl --request DELETE \
  --url http://localhost:5601/internal/alerting/v2/notification_policies/<ID> \
  --header 'Authorization: Basic <token>' \
  --header 'kbn-xsrf: true' \
  --header 'x-elastic-internal-origin: kibana'
```

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Introduces the `observability:alerting:dispatcherEnabled` Kibana Advanced
Setting to control whether the dispatcher task processes alert episodes.
When disabled, the task still runs on schedule but returns early doing no
work, preserving its state so no episodes are missed when re-enabled.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>