OU-1472: move support

.cursor/commands/fixture-schema-reference.md

@@ -189,16 +189,16 @@ cy.mockIncidentFixture(
 ### CLI Validation
 
 ```bash
-cd web/cypress/support/incidents_prometheus_query_mocks
+cd web/cypress/support/incidents
 node validate-fixtures.js --all
 node validate-fixtures.js specific-file.yaml
 ```
 
 ### Schema Files
 
-- Schema: `web/cypress/support/incidents_prometheus_query_mocks/fixture-schema.json`
-- Validator: `web/cypress/support/incidents_prometheus_query_mocks/schema-validator.ts`
-- CLI Tool: `web/cypress/support/incidents_prometheus_query_mocks/validate-fixtures.js`
+- Schema: `web/cypress/support/incidents/fixture-schema.json`
+- Validator: `web/cypress/support/incidents/schema-validator.ts`
+- CLI Tool: `web/cypress/support/incidents/validate-fixtures.js`
 
 ## Best Practices
 

.cursor/commands/generate-incident-fixture.md

@@ -9,12 +9,14 @@ Generate valid YAML fixtures for incident scenarios based on text descriptions o
 ## Process
 
 ### 1. Analyze Input
+
 - **Text Description**: Extract incident components, alert names, severities, and timeline
 - **Screenshot**: Identify visible incidents, alerts, and timeline - **CONVERT ALL DATES TO RELATIVE TIME**. There will be usually one chart 'Incident Timeline' displaying the incident timelines and second one 'Alert Timelines' which displays alerts for **a single particular incident**. When the Alert timeline is visible, include timestamps for the individual alerts within the incident, which may differ from the incident one.
 - Focus on capturing the precise start and end dates for incidents and individual alerts so that the variability from the screenshot is preserved.
 
 ### 2. Generate YAML Structure
-Create fixture following the schema in [fixture-schema.json](mdc:web/cypress/support/incidents_prometheus_query_mocks/fixture-schema.json). Prefer this schema over existing fixtures.
+
+Create fixture following the schema in [fixture-schema.json](mdc:web/cypress/support/incidents/fixture-schema.json). Prefer this schema over existing fixtures.
 
 ```yaml
 name: "[Scenario Name]"
@@ -36,6 +38,7 @@ incidents:
 ```
 
 ### 3. Apply Constraints
+
 - **Name and Description**: Use generic name capturing the essence of the scenario
 - **File name**: Use generic name capturing the essence of the scenario
 - **Components**: `monitoring`, `storage`, `network`, `compute`, `api-server`, `etcd`, `version`, `Others`
@@ -45,12 +48,14 @@ incidents:
 - **Alert Names**: Use descriptive, artificial names with unique indices (e.g., `"MonitoringAlertmanagerReceiversCritical001"`)
 
 ### 4. Time Conversion Rules
+
 - **NEVER use absolute dates/timestamps**
 - Convert screenshot dates to relative durations from the end of the chart
 - Example: If screenshot shows "2024-01-15 14:30" and current time is "2024-01-15 16:30", use `"2h"`
 
 ### 5. Run validation
-- run the validation using [fixture-schema.json](mdc:web/cypress/support/incident_prometheus_query_mocks/validate_fixture.js)
+
+- run the validation using [fixture-schema.json](mdc:web/cypress/support/incidents/validate_fixture.js)
 
 ```yaml
 
@@ -65,7 +70,8 @@ incidents:
 - [ ] Namespaces follow OpenShift conventions
 - [ ] Severity levels are valid (critical, warning, info)
 - [ ] YAML syntax is correct with proper indentation
-- [ ] Schema validation passes against [fixture-schema.json](mdc:web/cypress/support/incidents_prometheus_query_mocks/fixture-schema.json)
+- [ ] Schema validation passes against [fixture-schema.json](mdc:web/cypress/support/incidents/fixture-schema.json)
 
 ## Output
-Provide complete YAML fixture ready for use with `cy.mockIncidentFixture()` in Cypress tests.
+Provide complete YAML fixture ready for use with `cy.mockIncidentFixture()` in Cypress tests.
+```

.cursor/commands/generate-regression-test.md

@@ -2,6 +2,8 @@
 description: Generate automated regression test from test documentation
 ---
 
+TODO: UPDATE THIS WITH NEW STRUCTURE
+
 # Generate Regression Test
 
 Generate automated regression tests from test documentation in [`docs/incident_detection/tests/`](../../docs/incident_detection/tests/), following the style of existing tests in `@incidents/` and using `@incidents-page.ts` Page Object Model.
@@ -94,7 +96,7 @@ import { incidentsPage } from "../../../views/incidents-page";
 import {
   CLUSTER_MONITORING_OPERATOR,
   CLUSTER_OBSERVABILITY_OPERATOR,
-} from "../../../support/operators";
+} from "../../../support/shared/operators";
 
 describe("Regression: [Section Name]", () => {
   before(() => {
@@ -402,7 +404,7 @@ Which to follow?
 
 **Actions**:
 
-1. Search likely locations: `web/cypress/views/`, `web/cypress/support/page-objects/`
+1. Search likely locations: `web/cypress/views/`
 2. If different structure, attempt to adapt
 3. If not found:
    ```
@@ -534,7 +536,7 @@ import { incidentsPage } from "../../../views/incidents-page";
 import {
   CLUSTER_MONITORING_OPERATOR,
   CLUSTER_OBSERVABILITY_OPERATOR,
-} from "../../../support/operators";
+} from "../../../support/shared/operators";
 
 describe("Regression: Tooltip Positioning", () => {
   before(() => {
@@ -638,7 +640,7 @@ describe("Regression: Tooltip Positioning", () => {
 3. **Design comprehensive flow**: Instead of separate tests for each filter type, create complete filtering workflows
    - Flow 1: User applies multiple filters in sequence, verifies each step, then clears all
    - Flow 2: User changes time range while filters are active, verifies data updates
-4. Generate `01.reg_filtering.cy.ts` with **comprehensive multi-step tests**
+4. Generate `filtering.cy.ts` with **comprehensive multi-step tests**
 5. Each test should have 5-8 steps covering realistic filter combinations and transitions
 
 ## Output Format