@@ -45,7 +45,7 @@ prek is the single entrypoint for all lint, format, and type-checking tools. Bef
 
 ```bash
 SENTRY_MYPY_PRE_PUSH=1 .venv/bin/prek run -q mypy --files src/sentry/foo/bar.py --stage pre-push
-.venv/bin/prek run -q ruff --files src/sentry/foo/bar.py
+.venv/bin/prek run -q ruff-check --files src/sentry/foo/bar.py
 ```
 
 If a hook fails, fix the issues, stage changes, then re-run until it passes.
 
@@ -1,47 +1,42 @@
 # Backend Development Guide
 
-> For critical commands, see the "Command Execution Guide" section in `/AGENTS.md` in the repository root.
+> For setup, lint, and test commands, see the "Command Execution Guide" section in `/AGENTS.md` in the repository root.
 
 ## Security Guidelines
 
 ### Preventing Indirect Object References (IDOR)
 
-Multi-tenant queries MUST be scoped — never trust user-supplied IDs alone.
+Multi-tenant queries MUST be scoped. Never trust user-supplied IDs alone.
 
-- Always filter by `organization_id` and/or `project_id`:
+- Always filter by `organization_id` or `project_id`:
   `Resource.objects.get(id=..., organization_id=organization.id)`.
-- Never read `request.data["project_id"]` / `request.GET["project_id"]` directly. Use `self.get_projects(request=request, organization=organization, project_ids=...)`, which validates permissions.
+- Never read `request.data["project_id"]` or `request.GET["project_id"]` directly. Use `self.get_projects(request=request, organization=organization, project_ids=...)`, which checks permissions.
 
 For access-control review or deeper authorization work, use the **`django-access-review`** and **`sentry-security`** skills.
 
 ## Development Services
 
-Local dependencies are managed by `devservices` (config: `devservices/config.yml`).
-
-📖 Full devservices documentation: https://develop.sentry.dev/development-infrastructure/devservices.md
+`devservices` runs local dependencies from `devservices/config.yml`. Full documentation: https://develop.sentry.dev/development-infrastructure/devservices/
 
 ## AI Assistant Quick Decision Trees
 
 ### "User wants to add an API endpoint"
 
-1. Check if endpoint already exists: `grep -r "endpoint_name" src/sentry/api/`
-2. Inherit from appropriate base:
-   - Organization-scoped: `OrganizationEndpoint`
-   - Project-scoped: `ProjectEndpoint`
-   - Region silo: `RegionSiloEndpoint`
-3. File locations:
-   - Endpoint: `src/sentry/api/endpoints/{resource}.py`
-   - URL: `src/sentry/api/urls.py`
-   - Test: `tests/sentry/api/endpoints/test_{resource}.py`
-   - Serializer: `src/sentry/api/serializers/models/{model}.py`
-4. Document with drf-spectacular decorators → use the **`document-api-endpoint`** skill.
-
-### "User wants to add a Celery task"
-
-1. Location: `src/sentry/tasks/{category}.py`
-2. Use `@instrumented_task` decorator
-3. Set appropriate `queue` and `max_retries`
-4. Test location: `tests/sentry/tasks/test_{category}.py`
+1. Check whether the endpoint already exists: `grep -rn "endpoint_name" src/sentry/`.
+2. Inherit from the scope base: `OrganizationEndpoint` (`src/sentry/api/bases/organization.py`) or `ProjectEndpoint` (`src/sentry/api/bases/project.py`).
+3. Decorate the class with `@cell_silo_endpoint` or `@control_silo_endpoint` from `src/sentry/api/base.py`.
+4. Put the endpoint in the owning domain's `endpoints/` package (for example `src/sentry/core/endpoints/`) or in `src/sentry/api/endpoints/`. Register the route in `src/sentry/api/urls.py`, or in the domain `urls.py` it includes. The test file mirrors the endpoint path under `tests/`.
+5. Document it with drf-spectacular decorators → use the **`document-api-endpoint`** skill.
+
+### "User wants to add a task"
+
+Tasks run on taskbroker, not Celery.
+
+1. Decorate the function with `@instrumented_task` from `src/sentry/tasks/base.py`. Pass `name`, a `namespace` from `src/sentry/taskworker/namespaces.py`, and `retry=Retry(...)` from `taskbroker_client.retry` when the task retries.
+2. Add a new task module to `TASKWORKER_IMPORTS` in `src/sentry/conf/server.py`. `tests/sentry/taskworker/test_config.py` fails when a listed path does not import.
+3. The test file mirrors the module path under `tests/`.
+
+Full documentation: https://develop.sentry.dev/backend/application-domains/tasks/
 
 ### Serializers: Avoiding N+1 Queries
 
@@ -51,30 +46,25 @@ NEVER query the database in `serialize()` for bulk requests. `serialize()` runs
 
 ### API Documentation
 
-- OpenAPI spec generation: `make build-api-docs`
-- API ownership tracked in `src/sentry/apidocs/api_ownership_allowlist_dont_modify.py`
-- Documenting/typing an endpoint → use the **`document-api-endpoint`** skill.
+- Generate the OpenAPI spec with `make build-api-docs`.
+- API ownership is tracked in `src/sentry/apidocs/api_ownership_allowlist_dont_modify.py`.
 
 ### API Design Rules
 
 1. Route: `/api/0/organizations/{org}/projects/{project}/`
-2. Use `snake_case` for URL params
-3. Use `camelCase` for request/response bodies
-4. Return strings for numeric IDs
-5. Implement pagination with `cursor`
-6. Use `GET` for read, `POST` for create, `PUT` for update
-7. **Error responses MUST use the `"detail"` key** (Django REST Framework convention) — not `"error"` or `"message"`:
+2. Use `snake_case` for URL params.
+3. Use `camelCase` for request and response bodies.
+4. Return strings for numeric IDs.
+5. Paginate with `cursor`.
+6. Use `GET` to read, `POST` to create, `PUT` to update.
+7. **Error responses MUST use the `"detail"` key**, not `"error"` or `"message"`:
    `return Response({"detail": "Invalid input"}, status=400)`.
 
 ## Common Patterns
 
 ### Viewer/Organization Context
 
-Viewer identity is wired through the app via the `ViewerContext` contextvar; use `sentry.viewer_context.get_viewer_context()` instead of explicitly threading org/user identity when the current viewer is in scope.
-
-### Feature Flags
-
-See the **feature-flags** skill (`.agents/skills/feature-flags/`) for registration, the `features.has(...)` check, and test usage.
+The `ViewerContext` contextvar carries the current viewer's identity. When the viewer is in scope, call `sentry.viewer_context.get_viewer_context()` instead of passing org and user identity through arguments.
 
 ### Permissions
 
@@ -90,16 +80,15 @@ class MyPermission(SentryPermission):
 
 ### Logging, Tracing, Metrics, Options
 
-Logging (`logger.info/exception`, `LOG005`/`LOG011`), tracing/spans (`sentry.utils.tracing`), metrics tag cardinality, and the options system (`options.get()`) → use the **`backend-conventions`** skill.
+Logging (`LOG005`, `LOG011`), spans, metric tag cardinality, and `options.get()` → use the **`backend-conventions`** skill.
 
 ## Architecture Rules
 
 ### Silo Mode
 
-- **Control Silo**: User auth, billing, organization management
-- **Region Silo**: Project data, events, issues
-- Check model's silo in `src/sentry/models/outbox.py`; use `@cell_silo_endpoint` or `@control_silo_endpoint`.
-- Never join across silos; use `outbox` for cross-silo updates. For silo/RPC/outbox work, use the **`hybrid-cloud-rpc`**, **`hybrid-cloud-outboxes`**, and **`cell-architecture`** skills.
+- The control silo holds global data such as `User`, `Integration`, and `OrganizationMapping`. The cell silo holds organization-scoped data such as `Organization`, `Project`, and `Group`.
+- Each model declares its silo with `@control_silo_model` or `@cell_silo_model` (`src/sentry/db/models/base.py`). Each endpoint declares it with `@control_silo_endpoint` or `@cell_silo_endpoint`.
+- Never join across silos. Use outboxes (`src/sentry/hybridcloud/models/outbox.py`) for cross-silo updates. For silo, RPC, and outbox work, use the **`hybrid-cloud-rpc`**, **`hybrid-cloud-outboxes`**, and **`cell-architecture`** skills.
 
 ### Database Guidelines
 
@@ -110,24 +99,15 @@ Logging (`logger.info/exception`, `LOG005`/`LOG011`), tracing/spans (`sentry.uti
 
 ### Redis TTLs
 
-**Every new Redis key sets a TTL, or is registered with Infrastructure Engineering as accepted durable data.** `CommonRedisCache.set` and `RedisKVStorage.set` raise `MissingTTL` rather than write a key with no expiry. There is no opt-out argument: the exemption is granted by Infrastructure Engineering, not at the callsite.
-
-A bare `SET` or `GETSET` over an existing key clears its TTL; `SETEX` replaces it with the supplied expiry. `SADD`, `ZADD`, `HSET`, `HINCRBY` and `INCR` preserve an existing TTL. A TTL refreshed on every write does not bound the key's lifetime — shard by time window and give each shard a fixed TTL instead. Full rules: https://develop.sentry.dev/backend/application-domains/redis/.
+**Every new Redis key sets a TTL, or is registered with Infrastructure Engineering as accepted durable data.** `CommonRedisCache.set` and `RedisKVStorage.set` raise `MissingTTL` for a key with no expiry, and there is no opt-out argument. Which commands drop an existing TTL, and why a sliding TTL is not a bound: https://develop.sentry.dev/backend/application-domains/redis/
 
 ## Anti-Patterns (NEVER DO)
 
 ```python
-# WRONG: Direct model import in API
-from sentry.models import Organization  # NO!
-
-# RIGHT: Use endpoint bases
-from sentry.api.bases.organization import OrganizationEndpoint
-
-# WRONG: Synchronous external calls
+# WRONG: Slow external calls inside a request
 response = requests.get(url)  # NO!
 
-# RIGHT: Use Celery task
-from sentry.tasks import fetch_external_data
+# RIGHT: Move the call into a task (see "User wants to add a task")
 fetch_external_data.delay(url)
 
 # WRONG: N+1 queries
@@ -157,18 +137,19 @@ def my_function():
 
 ## File Location Map
 
-- **Models**: `src/sentry/models/{model}.py`
-- **API Endpoints**: `src/sentry/api/endpoints/{resource}.py`
+- **Models**: `src/sentry/models/{model}.py` or the owning domain's `models/` package
+- **API Endpoints**: `src/sentry/api/endpoints/{resource}.py` or `src/sentry/{domain}/endpoints/`
 - **Serializers**: `src/sentry/api/serializers/models/{model}.py`
-- **Tasks**: `src/sentry/tasks/{category}.py`
+- **Tasks**: `src/sentry/tasks/{category}.py` or `src/sentry/{domain}/tasks/`
+- **Task namespaces**: `src/sentry/taskworker/namespaces.py`
 - **Integrations**: `src/sentry/integrations/{provider}/`
 - **Permissions**: `src/sentry/api/permissions.py`
 - **Feature Flags**: `src/sentry/features/permanent.py` or `temporary.py`
 - **Utils**: `src/sentry/utils/{category}.py`
 
 ## Integration Development
 
-Add an integration under `src/sentry/integrations/{name}/` with `__init__.py`, `integration.py` (inherit from `Integration`), `client.py` (API client), and `webhooks/` if needed. Register it in `src/sentry/integrations/registry.py` and add a feature flag in `temporary.py`.
+Add an integration under `src/sentry/integrations/{name}/`. Subclass `IntegrationProvider` and `IntegrationInstallation` from `src/sentry/integrations/base.py`; `src/sentry/integrations/example/integration.py` is a working reference. Register the provider class path in `SENTRY_DEFAULT_INTEGRATIONS` in `src/sentry/conf/server.py`, and gate it with a flag in `src/sentry/features/temporary.py`.
 
 ## Python Typing
 
 
@@ -8,11 +8,11 @@ Incoming webhooks fired by integration providers notify us when changes occur in
 
 ## How it Works
 
-The magic happens in the [`IntegrationControlMiddleware`](src/sentry/middleware/integrations/integration_control.py). Here, we do the following steps:
+The magic happens in the [`IntegrationControlMiddleware`](/src/sentry/middleware/integrations/integration_control.py). Here, we do the following steps:
 
 - If an HTTP request is received to `/extensions/*` (which is the prefix for all our webhooks) it is further inspected. If not, we fall through this middleware.
 - Next, we try to identify the parser from the provider, since these requests follow the pattern `/extensions/provider/webhook-path/`. If no parser is registered, we fall through this middleware
-- If we've found a parser ([`BaseRequestParser`](src/sentry/integrations/middleware/hybrid_cloud/parsers.py)), we defer to it for responding to the request, rather than falling through.
+- If we've found a parser ([`BaseRequestParser`](/src/sentry/integrations/middleware/hybrid_cloud/parser.py)), we defer to it for responding to the request, rather than falling through.
 
 The parsers vary per integration but they follow the same basic steps:
 
@@ -22,7 +22,7 @@ The parsers vary per integration but they follow the same basic steps:
 - Lastly, identify the relevant Cell Silos we need to forward to from looking at the `OrganizationMapping`s.
 - Now, depending on the payload we can choose how to respond to the initial request:
   - Some requests will require synchronous responses with an expected response pattern, (e.g. Slack).
-  - Others don't care about the response, and we may opt to handle them asynchronously via the [`ControlOutbox` model](src/sentry/hybridcloud/models/outbox.py), (e.g. GitHub).
+  - Others don't care about the response, and we may opt to handle them asynchronously via the [`ControlOutbox` model](/src/sentry/hybridcloud/models/outbox.py), (e.g. GitHub).
   - And others may require fanning out identical webhooks to multiple cells where the integration is installed on an organization, (e.g. Jira).
 
 ## Adding Integration Parsers
@@ -57,9 +57,12 @@ class ExampleRequestParser(BaseRequestParser):
 
 ```
 
-You can register it and start forwarding requests when Sentry is running as a Control Silo by adding it to [`integeration_control.py`](src/sentry/middleware/integrations/integration_control.py):
+Put the parser in [`parsers/`](/src/sentry/middleware/integrations/parsers/), then register it by importing it and adding it to `active_parsers` in `IntegrationClassification.integration_parsers` in [`classifications.py`](/src/sentry/middleware/integrations/classifications.py):
 
 ```diff
-- ACTIVE_PARSERS = [SlackRequestParser]
-+ ACTIVE_PARSERS = [SlackRequestParser, ExampleRequestParser]
+  active_parsers: list[type[BaseRequestParser]] = [
+      BitbucketRequestParser,
++     ExampleRequestParser,
+      ...
+  ]
 ```
@@ -15,7 +15,7 @@ The proxying is managed by the [`IntegrationProxyClient`](/src/sentry/shared_int
   ```
   {SENTRY_CONTROL_ADDRESS}/api/0/internal/integration-proxy # PROXY_BASE_PATH
   ```
-  The [integration proxy endpoint](/src/sentry/api/endpoints/internal/integration_proxy.py) parses the headers to verify the request is coming from a valid Region silo, and then replays the request with the proper authentication data (from `self.authorize_request`). The raw response is sent back to the originating silo to handle itself!
+  The [integration proxy endpoint](/src/sentry/integrations/api/endpoints/integration_proxy.py) parses the headers to verify the request is coming from a valid Region silo, and then replays the request with the proper authentication data (from `self.authorize_request`). The raw response is sent back to the originating silo to handle itself!
 
 ## Implementing the IntegrationProxyClient
 
 
@@ -520,8 +520,9 @@ condition handler alone cannot add detector packet data or detector-specific API
 
 These are separate decisions, not part of backend registration.
 
-For legacy issue-alert compatibility, add a forward translation in
-[`migration_helpers/issue_alert_conditions.py`](../migration_helpers/issue_alert_conditions.py).
+Production code no longer translates legacy issue-alert conditions. Test factories still do,
+through `data_condition_translator_mapping` in
+[`testutils/helpers/issue_alert_conditions.py`](../../testutils/helpers/issue_alert_conditions.py).
 
 For the automation builder, add the matching frontend enum and node implementation in a
 separate frontend PR:
@@ -546,7 +547,7 @@ have explicit frontend nodes, defaults, details, and validation.
 | Add slow condition                  | `SLOW_CONDITIONS`, `event_frequency_query_handlers.py`, delayed query/result code, delayed processor tests |
 | Change API validation               | `endpoints/validators/base/data_condition.py` and group/Detector/Workflow validators                       |
 | Change availability metadata        | `endpoints/organization_data_condition_index.py` and handler serializer                                    |
-| Add legacy compatibility            | `migration_helpers/issue_alert_conditions.py`                                                              |
+| Add legacy test translation         | `src/sentry/testutils/helpers/issue_alert_conditions.py`                                                   |
 | Add automation UI                   | Frontend condition enum, node registry, editor/details components, frontend tests                          |
 
 ## Conventions and Invariants
 
@@ -12,9 +12,8 @@ The deprecated legacy alert API routes were removed in
 the detector and workflow APIs to manage alerts. The serializer and issue-alert
 POST/PUT rollout flags no longer have consumers and have been retired.
 
-Some compatibility code remains: rule history and statistics resolve legacy rule IDs
-to workflows, lookup endpoints expose associations between legacy and Workflow Engine
-models, and notification code still uses legacy-shaped data. Endpoint retirement does
+Some compatibility code remains: lookup endpoints expose associations between legacy and
+Workflow Engine models, and notification code still uses legacy-shaped data. Endpoint retirement does
 not imply that the association tables, serializers, or ID helpers are all unused.
 
 ## Handling IDs
@@ -41,8 +40,8 @@ Endpoints that accept IDs as input must handle both real legacy IDs (via associa
 ## Compatibility Endpoints
 
 Check the registered routes and their implementations when changing compatibility
-code. Rule history and statistics live in `src/sentry/rules/history/endpoints/`;
-association lookup routes live in `src/sentry/workflow_engine/endpoints/urls.py`.
+code. The association lookup routes (`alert-rule-workflow`, `alert-rule-detector`, and
+`incident-groupopenperiod`) live in `src/sentry/workflow_engine/endpoints/urls.py`.
 The endpoint-tracking decorator was removed with the deprecated routes.
 
 ## Unsupported legacy features