Merge branch 'main' into chore/move-dashboard-and-lens-overlays

Author: jloleysens

.agents/skills/accessibility/references/components/index.md

@@ -12,4 +12,5 @@ Open the guide that matches the component(s) you are writing or refactoring. Rea
 | `interactive_components.md` | Names for interactive controls | `EuiBetaBadge`, `EuiButtonIcon`, `EuiComboBox`, `EuiSelect`, `EuiSuperSelect`, `EuiPagination`, `EuiTreeView`, `EuiBreadcrumbs` |
 | `overlays.md` | Modals, flyouts, popovers | `EuiModal`, `EuiFlyout`, `EuiFlyoutResizable`, `EuiConfirmModal`, `EuiPopover` |
 | `radio_groups.md` | Radio groups (`name` grouping) | `EuiRadio`, `EuiRadioGroup` |
-| `tooltip_icon.md` | Tooltip on icon button (no duplicate SR text) | `EuiToolTip`, `EuiButtonIcon` |
+| `tooltip_content.md` | No interactive elements in tooltip `content` / `title` | `EuiToolTip`, `EuiIconTip` |
+| `tooltip_icon.md` | Tooltip on icon button (wrap + no duplicate SR text, no native `title`) | `EuiToolTip`, `EuiButtonIcon` |

.agents/skills/accessibility/references/components/tooltip_content.md

@@ -0,0 +1,95 @@
+# EUI tooltip content: no interactive elements
+
+**Applies to:** `EuiToolTip`, `EuiIconTip` — the `content` and `title` props
+
+Tooltip `content` and `title` render inside a portal with `role="tooltip"`. The overlay only appears while the trigger is hovered or focused and is dismissed on blur, so any focusable element placed inside it is unreachable by keyboard and assistive-technology users. Use **`EuiPopover`** when the content needs to be interactive.
+
+**Related guides:** **`overlays.md`** (`EuiPopover` for interactive content) · **`tooltip_icon.md`** (wrapping `EuiButtonIcon` with `EuiToolTip`) · **`icons_and_tooltips.md`** (`EuiIconTip` vs `EuiToolTip` + `EuiIcon`).
+
+## Canonical usage
+
+- `EuiToolTip` / `EuiIconTip` `content` and `title` may contain:
+  - **Plain strings** (preferred — easy to localize and read).
+  - **Non-interactive JSX** — text nodes, `<span>`, `<p>`, `EuiText`, `EuiIcon`, and the display-only badges/cards (`EuiBadge`, `EuiBetaBadge`, `EuiCard`) used **without** `onClick` / `href`.
+- They must **not** contain anything focusable:
+  - Native `<a>`, `<button>`, `<input>`, `<select>`, `<textarea>`.
+  - Interactive EUI components — `EuiLink`, `EuiButton`, `EuiButtonEmpty`, `EuiButtonIcon`, `EuiFieldText`, `EuiFieldNumber`, `EuiFieldSearch`, `EuiFieldPassword`, `EuiTextArea`, `EuiSelect`, `EuiSuperSelect`, `EuiComboBox`, `EuiSelectable`, `EuiSwitch`, `EuiCheckbox`, `EuiRadio`, `EuiRange`, `EuiDualRange`, `EuiColorPicker`, `EuiDatePicker`, `EuiSuperDatePicker`, `EuiFilterButton`, `EuiPagination`, `EuiTab`, `EuiTreeView`, `EuiContextMenuItem`, `EuiKeyPadMenuItem`, `EuiListGroupItem`, `EuiBreadcrumbs`, `EuiBasicTable`, `EuiInMemoryTable`, `EuiCheckableCard`, …
+- The rule searches recursively — interactive elements nested inside fragments, conditional renders (`cond && …`, `cond ? … : …`), or wrapper elements are reported too.
+- When users need to interact with the content (click a link, fill a field), switch the wrapper to **`EuiPopover`** triggered by an explicit click — never by hover.
+
+### Manual-review cases (rule is silent)
+
+- **Variable content** — `content={tooltipContent}` / `title={titleNode}` is intentionally skipped because it cannot be statically analyzed. Trace the variable and verify it never holds focusable JSX.
+- **Conditionally-interactive components** — `EuiBadge`, `EuiBetaBadge`, `EuiCard` are excluded from the rule because they render as a plain element without `onClick` / `href`. As soon as you add `onClick` or `href`, they become focusable and the same restriction applies — move the interaction out of the tooltip.
+
+## Examples
+
+```tsx
+<EuiToolTip content="Just text">
+  <EuiButton>Hover me</EuiButton>
+</EuiToolTip>
+
+<EuiToolTip content={<EuiText><p>Description</p></EuiText>}>
+  <EuiButton>Hover me</EuiButton>
+</EuiToolTip>
+
+<EuiIconTip content="Informational text" type="info" />
+
+// Display-only badge is fine
+<EuiToolTip content={<EuiBadge>v2.0</EuiBadge>}>
+  <EuiButton>Hover me</EuiButton>
+</EuiToolTip>
+```
+
+## Common mistakes
+
+```tsx
+// WRONG — link inside tooltip is not keyboard-reachable
+<EuiToolTip content={<EuiLink href="/docs">Learn more</EuiLink>}>
+  <EuiButton>Hover me</EuiButton>
+</EuiToolTip>
+
+// RIGHT — switch to EuiPopover so the link participates in the focus order
+const [isOpen, setIsOpen] = useState(false);
+const togglePopover = () => setIsOpen((open) => !open);
+const closePopover = () => setIsOpen(false);
+
+<EuiPopover
+  button={<EuiButton onClick={togglePopover}>More info</EuiButton>}
+  isOpen={isOpen}
+  closePopover={closePopover}
+>
+  <EuiLink href="/docs">Learn more</EuiLink>
+</EuiPopover>
+
+// WRONG — button inside `EuiIconTip` content
+<EuiIconTip content={<EuiButton>Click</EuiButton>} type="info" />
+
+// RIGHT — keep the icon tip purely informational
+<EuiIconTip content="Informational text" type="info" />
+
+// WRONG — interactive element inside `title` is also reported
+<EuiToolTip title={<EuiLink href="#">Learn more</EuiLink>} content="Info">
+  <EuiButton>Hover</EuiButton>
+</EuiToolTip>
+
+// WRONG — interactive child wrapped in a fragment is reported recursively
+<EuiToolTip content={<><span>Text</span><EuiLink href="#">Link</EuiLink></>}>
+  <EuiButton>Hover</EuiButton>
+</EuiToolTip>
+
+// WRONG — interactive child behind `cond && …` is reported
+<EuiToolTip content={<span>{cond && <EuiLink href="#">Link</EuiLink>}</span>}>
+  <EuiButton>Hover</EuiButton>
+</EuiToolTip>
+
+// WRONG — interactive child inside a ternary is reported
+<EuiToolTip content={cond ? <EuiLink href="#">Link</EuiLink> : null}>
+  <EuiButton>Hover</EuiButton>
+</EuiToolTip>
+
+// WRONG — conditionally-interactive badge with onClick becomes focusable
+<EuiToolTip content={<EuiBadge onClick={onClick}>Open</EuiBadge>}>
+  <EuiButton>Hover</EuiButton>
+</EuiToolTip>
+```

.agents/skills/accessibility/references/components/tooltip_icon.md

@@ -2,49 +2,58 @@
 
 **Applies to:** `EuiToolTip`, `EuiButtonIcon`
 
-When **`EuiToolTip`** wraps **`EuiButtonIcon`** and the tooltip **`content`** matches the button's **`aria-label`**, assistive technology can announce the same text twice. Use **`disableScreenReaderOutput`** so the tooltip stays available to sighted users while screen readers hear the name once.
+Every **`EuiButtonIcon`** needs two things:
 
-**Related guides:** **`focus_and_keyboard.md`** (tooltip anchors / `tabIndex`) · **`icons_and_tooltips.md`** (`EuiIconTip` vs `EuiToolTip` + `EuiIcon`).
+1. **A visible tooltip for sighted users** — wrap the button with **`EuiToolTip`**. Do **not** use the native **`title`** prop on `EuiButtonIcon`; browser tooltips are unstyled, have no delay control, and are not reliably announced by screen readers across browser / AT combinations.
+2. **An accessible name for assistive technology** — keep **`aria-label`** on the button.
 
-## Canonical usage
+When the tooltip **`content`** and the button's **`aria-label`** match (same string, same variable, or same `i18n` call), also set **`disableScreenReaderOutput`** on `EuiToolTip` so screen readers announce the name once instead of twice.
 
-- **`content`** equals **`aria-label`** (same string or same variable / same `i18n` call) → set **`disableScreenReaderOutput`** on **`EuiToolTip`**.
-- **`content`** differs from **`aria-label`** → no extra prop; both will be announced as intended.
-- Child is not **`EuiButtonIcon`** → this pattern doesn't apply; check the related guides above.
+**Related guides:** **`focus_and_keyboard.md`** (tooltip anchors / `tabIndex`) · **`icons_and_tooltips.md`** (`EuiIconTip` vs `EuiToolTip` + `EuiIcon`) · **`tooltip_content.md`** (no interactive elements inside tooltip `content` / `title`).
 
-Prefer a single **`i18n.translate`** call (same id + `defaultMessage`) for both **`content`** and **`aria-label`** so the strings can't drift apart.
+## Canonical usage
 
-For `{...tooltipProps}` spreads, merge **`disableScreenReaderOutput`** at the callsite or in the spread source.
+1. Wrap every `EuiButtonIcon` with `EuiToolTip`. Remove any `title` prop from the button.
+2. Pass the same localized string to `EuiToolTip` `content` and the button's `aria-label`. Prefer a single **`i18n.translate`** call (same id + `defaultMessage`) referenced from both places so the strings cannot drift apart.
+3. When `content` and `aria-label` match → add **`disableScreenReaderOutput`** on `EuiToolTip`.
+4. When `content` and `aria-label` intentionally differ (the tooltip elaborates beyond the name) → do **not** add `disableScreenReaderOutput`; both will be announced as intended.
 
 ## Examples
 
 ```tsx
-<EuiToolTip
-  content={i18n.translate('filter.add', { defaultMessage: 'Add filter' })}
-  disableScreenReaderOutput
->
+const editLabel = i18n.translate('myFeature.editItem', {
+  defaultMessage: 'Edit item',
+});
+
+<EuiToolTip content={editLabel} disableScreenReaderOutput>
   <EuiButtonIcon
-    iconType="plusInCircle"
-    aria-label={i18n.translate('filter.add', { defaultMessage: 'Add filter' })}
-    onClick={onAdd}
+    iconType="pencil"
+    aria-label={editLabel}
+    onClick={onEdit}
   />
 </EuiToolTip>
 ```
 
 ## Common mistakes
 
 ```tsx
-// WRONG — screen reader announces "Add filter" twice
-<EuiToolTip content={label}>
-  <EuiButtonIcon iconType="plusInCircle" aria-label={label} onClick={onAdd} />
+// WRONG — no visible tooltip for sighted users
+<EuiButtonIcon iconType="trash" aria-label="Delete" onClick={onDelete} />
+
+// WRONG — native `title` is not reliably announced by screen readers and has no consistent visual styling
+<EuiButtonIcon title="Delete" aria-label="Delete" iconType="trash" onClick={onDelete} />
+
+// WRONG — tooltip and `aria-label` without `disableScreenReaderOutput` will lead to SR announcement duplication
+<EuiToolTip content="Delete">
+  <EuiButtonIcon iconType="trash" aria-label="Delete" onClick={onDelete} />
 </EuiToolTip>
 
-// RIGHT
-<EuiToolTip content={label} disableScreenReaderOutput>
-  <EuiButtonIcon iconType="plusInCircle" aria-label={label} onClick={onAdd} />
+// RIGHT — wrap, keep `aria-label`, and add `disableScreenReaderOutput` when `content` matches
+<EuiToolTip content="Delete" disableScreenReaderOutput>
+  <EuiButtonIcon iconType="trash" aria-label="Delete" onClick={onDelete} />
 </EuiToolTip>
 
-// WRONG — different ids, strings may drift apart
+// WRONG — different i18n ids may drift apart
 content={i18n.translate('a.tooltip', { defaultMessage: 'Add' })}
 aria-label={i18n.translate('a.button', { defaultMessage: 'Add' })}
 

.agents/skills/accessibility/references/eslint.md

@@ -15,4 +15,6 @@ Secondary path: when starting from a rule id, jump to the canonical **component
 | `@elastic/eui/require-aria-label-for-modals` | [`components/overlays.md`](components/overlays.md) | `{...props}` hides wiring; no visible title without UX change — escalate. |
 | `@elastic/eui/require-table-caption` | [`components/data_tables.md`](components/data_tables.md) | `tableCaption` only via `{...tableProps}` — fix at source; no duplicate conflicting captions. |
 | `@elastic/eui/sr-output-disabled-tooltip` | [`components/tooltip_icon.md`](components/tooltip_icon.md) | `EuiToolTip` props from spread; child not `EuiButtonIcon`. |
+| `@elastic/eui/tooltip-button-icon-wrap` | [`components/tooltip_icon.md`](components/tooltip_icon.md) | `{...props}` without an explicit `title` is silently skipped — verify the spread does not omit a tooltip. No `aria-label` on the button → autofix can't run; supply both `aria-label` and `EuiToolTip` `content`. |
 | `@elastic/eui/tooltip-focusable-anchor` | [`components/focus_and_keyboard.md`](components/focus_and_keyboard.md) | `{...anchorProps}` or unknown custom anchor. |
+| `@elastic/eui/tooltip-no-interactive-content` | [`components/tooltip_content.md`](components/tooltip_content.md) | Variable content (`content={var}` / `title={var}`) is silently skipped — trace and verify. `EuiBadge` / `EuiBetaBadge` / `EuiCard` with `onClick` / `href` become focusable and need migration to `EuiPopover`. |

.agents/skills/evals-write-spec/SKILL.md

@@ -24,7 +24,7 @@ evaluate.describe('Suite name', { tag: tags.serverless.observability.complete },
 
   evaluate('test name', async ({ executorClient, connector }) => {
     await executorClient.runExperiment(
-      { dataset, task },
+      { datasets: [dataset], task },
       evaluators
     );
   });
@@ -202,7 +202,7 @@ export function createEvaluateDataset({
   return async ({ dataset }) => {
     await executorClient.runExperiment(
       {
-        dataset,
+        datasets: [dataset],
         task: async ({ input }) => {
           const response = await chatClient.converse({ messages: [{ message: input.question }] });
           return { messages: response.messages, steps: response.steps };

.agents/skills/evals-write-spec/references/evaluator-patterns.md

@@ -20,7 +20,7 @@ type MyTaskOutput = TaskOutput & {
 };
 
 await executorClient.runExperiment(
-  { dataset, task },
+  { datasets: [dataset], task },
   selectEvaluators<MyExample, MyTaskOutput>([
     {
       name: 'NonEmptyDocuments',
@@ -246,7 +246,7 @@ A common pattern passes both CODE and LLM evaluators to `runExperiment`:
 
 ```ts
 await executorClient.runExperiment(
-  { dataset, task },
+  { datasets: [dataset], task },
   [
     createCriteriaEvaluator({ evaluators }),
     createToolCallsEvaluator({ evaluators }),

.agents/skills/flaky-test-investigator/SKILL.md

@@ -42,8 +42,6 @@ For every failure, try to retrieve:
 - **Server logs** (`kibana.log`, `elasticsearch.log` when present). Cross-reference the failure timestamp with any errors in the logs — a server-side 500 or unexpected warning is strong evidence the failure is a product bug, not a test bug.
 - **Full session trace** when the framework supports it (Scout / Playwright). Lets you scrub through every step, locator query, network call, and DOM snapshot.
 
-How to actually find and download each artifact type is framework-specific — see "Retrieve failure artifacts" below.
-
 Things to specifically check in the artifacts before forming a root-cause hypothesis:
 
 - **Did the expected element render at all?** If yes and the selector missed it → flaky selector (Tier 2 fix territory). If no → real rendering / race / data issue (Tier 1 territory).
@@ -53,27 +51,9 @@ Things to specifically check in the artifacts before forming a root-cause hypoth
 
 If artifacts are not available (expired, not uploaded, no `read_artifacts` token), say so in the report rather than fabricating a hypothesis. "Screenshot would have resolved this; not available" is a valid open question.
 
-### Retrieve failure artifacts
-
-The standard recipe is **list → filter by path → download by ID**, always scoped to the failed job's UUID. Two Buildkite gotchas to know about first:
-
-- **Failed-attempt jobs are hidden by default.** `/builds/<n>` returns only the latest attempt; append `?include_retried_jobs=true` to find the original failing job (the one cited in `failed-test` comments). `retried` and `retried_in_job_id` link the two.
-- **Per-job artifacts use a different endpoint than build-wide artifacts.** If a build retried to green, failure artifacts only live on the failed job's listing (`bk artifacts list <build> -p <pipeline> --job-uuid <jobId>`). Don't conclude "no screenshot uploaded" until you've checked there.
-
-**Scout** (`@kbn/scout-reporting`, not standard Playwright output — `playwright-report/`, `trace.zip`, and video are NOT published):
-
-- `.scout/reports/scout-playwright-test-failures-<runId>/test-failures-summary.json` — maps test name → HTML report. Start here.
-- `.scout/reports/scout-playwright-test-failures-<runId>/<testId>.html` — self-contained: error, stdout, embedded screenshot. Usually sufficient on its own.
-- `.scout/reports/scout-playwright-test-failures-<runId>/scout-failures-<runId>.ndjson` — one record per failure (`id` = `<testId>`, `owner`, `location`, `error.*`) for programmatic use.
-- `**/.scout/test-artifacts/<test-slug>/test-failed-<N>.png` — plain Playwright screenshot; the PNG doesn't carry `<testId>`, so correlate via spec path.
-
-**FTR** (a single content `<hash>` links every artifact for one failure):
-
-- `target/test_failures/<jobId>_<hash>.{json,log,html}` — `.json` is source of truth; full Kibana/ES stdout lives in `system-out` (there is no separate `kibana.log`). Pull this first.
-- `<test-root>/screenshots/failure/*-<hash>.png` and `<test-root>/failure_debug/html/*-<hash>.html` — UI tests only; fetch only when the failure is UI-side.
-- `.es/*.log` — transport/cluster-shaped failures.
+### List failure artifacts
 
-`target/test_failures/` is shared with Scout; filter by `.jobName` (e.g. `FTR Configs #90` vs `Scout Lane #12`) to keep only FTR. On Cloud FTR pipelines the layout differs: one self-contained HTML per failure at `<config-path-with-underscores>-<unix-timestamp>/html/<contentHash>.html` — no `target/test_failures/`, screenshot, or DOM artifacts.
+`bk artifacts list <build> -p <pipeline> --job-uuid <jobId> --json` returns a JSON listing of every artifact uploaded for the failing job. Pass `--job-uuid <jobId>` for the failed attempt (without it, `bk` only returns the latest attempt and hides retried failures). If a build retried to green, failure artifacts only live on the failed job's listing; don't conclude "no screenshot" until you've scoped to the right job UUID.
 
 ### Understand the scope