@elliemae/ds-data-table 3.70.0-next.3 → 3.70.0-next.4

package/skills/ds-data-table-filtering/SKILL.md

@@ -0,0 +1,322 @@
+---
+name: ds-data-table-filtering
+description: >
+  V2 filter system for @elliemae/ds-data-table. FILTER_TYPES V2 values (MULTI_SELECT_V2,
+  SELECT_V2, etc.), column-level filter config, filterOptions for multi-select, controlled
+  filters + onFiltersChange handler, applyOutOfTheBoxFilters, withFilterBar, filterBarProps,
+  composable DSFilterBar + PillsFromDataTableFilters. V1 filter strings are a11y-unsafe tech
+  debt — migrate to V2 whenever found in existing code, never use in new implementations.
+type: core
+library: ds-data-table
+library_version: '3.60.0'
+requires:
+  - ds-data-table-setup
+  - ds-filter-bar-setup
+sources:
+  - '@elliemae/ds-data-table:dist/types/exported-related/FilterTypes.d.ts'
+  - '@elliemae/ds-data-table:dist/types/react-desc-prop-types.d.ts'
+---
+
+## Setup
+
+```jsx
+import { DataTable, FILTER_TYPES, applyOutOfTheBoxFilters } from '@elliemae/ds-data-table';
+
+const columns = [
+  { Header: 'ID', accessor: 'id', filter: FILTER_TYPES.MULTI_SELECT_V2 },
+  {
+    Header: 'Position',
+    accessor: 'position',
+    filter: FILTER_TYPES.MULTI_SELECT_V2,
+    filterOptions: [
+      { dsId: '1', type: 'option', value: 'React dev', label: 'React dev' },
+      { dsId: '2', type: 'option', value: 'Fullstack dev', label: 'Fullstack dev' },
+    ],
+  },
+];
+
+// In your state manager — adapt to Redux/Zustand/Jotai
+const [filters, setFilters] = /* state manager slice */;
+const [filteredData, setFilteredData] = /* state manager slice */;
+
+// onFiltersChange MUST be memoized
+const onFiltersChange = useCallback((newFilters) => {
+  dispatch(setFilters(newFilters));
+  dispatch(setFilteredData(applyOutOfTheBoxFilters(originalData, newFilters)));
+}, [originalData]);
+
+<DataTable
+  columns={columns}
+  data={filteredData}
+  height={500}
+  withFilterBar
+  filters={filters}
+  onFiltersChange={onFiltersChange}
+/>
+```
+
+## Core Patterns
+
+### Available V2 filter types
+
+```js
+import { FILTER_TYPES } from '@elliemae/ds-data-table';
+
+// V2 types — always use these
+FILTER_TYPES.MULTI_SELECT_V2; // multi-select dropdown
+FILTER_TYPES.SELECT_V2; // single-select dropdown
+FILTER_TYPES.CREATABLE_SELECT_V2; // single-select with user-creatable options
+FILTER_TYPES.CREATABLE_MULTI_SELECT_V2; // multi-select with user-creatable options
+FILTER_TYPES.SINGLE_DATE_V2; // single date picker
+FILTER_TYPES.DATE_RANGE_V2; // date range picker
+FILTER_TYPES.DATE_SWITCHER_V2; // date / date-range toggle
+FILTER_TYPES.NUMBER_RANGE_V2; // numeric range input
+FILTER_TYPES.FREE_TEXT_SEARCH_V2; // text input
+FILTER_TYPES.CURRENCY_RANGE_V2; // currency range input
+
+// V1 types — DO NOT USE, migrate on sight
+FILTER_TYPES.MULTI_SELECT; //  ← a11y-unsafe legacy
+FILTER_TYPES.SELECT; //  ← a11y-unsafe legacy
+FILTER_TYPES.CREATABLE_SELECT; //  ← a11y-unsafe legacy
+FILTER_TYPES.CREATABLE_MULTI_SELECT; //  ← a11y-unsafe legacy
+FILTER_TYPES.SINGLE_DATE; //  ← a11y-unsafe legacy
+FILTER_TYPES.DATE_RANGE; //  ← a11y-unsafe legacy
+FILTER_TYPES.DATE_SWITCHER; //  ← a11y-unsafe legacy
+FILTER_TYPES.NUMBER_RANGE; //  ← a11y-unsafe legacy
+FILTER_TYPES.FREE_TEXT_SEARCH; //  ← a11y-unsafe legacy
+FILTER_TYPES.CURRENCY_RANGE; //  ← a11y-unsafe legacy
+```
+
+### Composable filter bar with external DSFilterBar
+
+The composable pattern pairs `PillsFromDataTableFilters` (this package) with `DSFilterBar` from `@elliemae/ds-filter-bar`. The `@elliemae/ds-filter-bar` assembly has its own a11y requirements (focus management, screen reader announcements) that are outside the scope of this skill.
+
+**Before implementing the filter bar assembly:**
+
+1. Load the `ds-filter-bar-setup` skill from `@elliemae/ds-filter-bar` — run `npx @tanstack/intent install` in the project or look for a `skills/` directory inside the package. That skill covers the full assembly: `useFilterBarPrevNextFocus`, `runAfterRemoval`, `ScreenReaderOnly` announcements, `DSFilterBarMenuButton` wiring, and all a11y requirements.
+2. If no skill is found, ask the human to share a correct implementation example from the Dimsum storybook. Do not approximate the filter bar assembly from incomplete information — omitting the focus management hooks breaks keyboard accessibility.
+
+The DataTable side of the wiring:
+
+```jsx
+import { DataTable, PillsFromDataTableFilters, applyOutOfTheBoxFilters } from '@elliemae/ds-data-table';
+import {} from /* see @elliemae/ds-filter-bar skill or storybook */ '@elliemae/ds-filter-bar';
+import { useCallback, useRef } from 'react';
+
+const onFiltersChange = useCallback(
+  (newFilters) => {
+    dispatch(setFilters(newFilters));
+    dispatch(setFilteredData(applyOutOfTheBoxFilters(originalData, newFilters)));
+  },
+  [originalData],
+);
+
+// fallbackRef is shared with the DSFilterBar assembly (passed as fallbackRef to
+// useFilterBarPrevNextFocus). When the last filter pill is removed, the filter bar
+// has nowhere left to move focus — this ref tells it to land on the first column header.
+const fallbackRef = useRef(null);
+
+// dsDatatableHeadTh injects fallbackRef into the first focusable column header,
+// completing the focus chain: last pill removed → focus moves to table header
+const dsDatatableHeadTh = useCallback(({ columnId, firstFocuseableColumnHeaderId }) => {
+  if (columnId === firstFocuseableColumnHeaderId) return { innerRef: fallbackRef };
+  return {};
+}, []);
+
+{
+  /*
+  ... DSFilterBar assembly here (from @elliemae/ds-filter-bar).
+  Use PillsFromDataTableFilters inside DSFilterBarContent.
+  Follow all a11y requirements from the ds-filter-bar skill or storybook —
+  do not omit focus management hooks or ScreenReaderOnly announcements.
+*/
+}
+
+<DataTable
+  columns={columns}
+  data={filteredData}
+  height={500}
+  filters={filters}
+  onFiltersChange={onFiltersChange}
+  dsDatatableHeadTh={dsDatatableHeadTh}
+/>;
+```
+
+Do not pass `withFilterBar` to DataTable when using a composable `DSFilterBar` — the filter bar is external.
+
+### filterBarProps for inline filter bar customization
+
+`filterBarAddonRenderer` must be a **stable React component reference** — defined at module level or imported, never inline or via `useCallback`. Defining it inline (even with `useCallback`) creates a new component type on re-render, causing React to unmount and remount the addon on every render cycle, producing erratic behavior whenever the addon uses hooks or internal state.
+
+The addon needs access to filter state and clear action from outside itself. Because `FilterBarAddon` is at module level, it reads what it needs at render time rather than closing over parent state — that is what makes this pattern work. Adapt to your project's state management stack:
+
+- **Redux**: define `FilterBarAddon` at module level and connect directly with `useSelector`/`useDispatch` — no context needed
+- **Zustand / Jotai**: subscribe to the relevant store or atom directly inside `FilterBarAddon`
+- **React Context**: use the pattern below (last resort — prefer the state manager options above)
+
+```jsx
+import { DSButtonV3 } from '@elliemae/ds-button-v2';
+import { ScreenReaderOnly } from '@elliemae/ds-accessibility';
+import { DataTable, applyOutOfTheBoxFilters } from '@elliemae/ds-data-table';
+import React, { createContext, useCallback, useContext, useState, useMemo } from 'react';
+
+const FilterBarAddonContext = createContext(null);
+
+const FilterBarAddon = () => {
+  const { filters, onClearFilters } = useContext(FilterBarAddonContext);
+  if (filters.length === 0) return null;
+  return (
+    <DSButtonV3 buttonType="text" onClick={onClearFilters}>
+      Clear all filters
+    </DSButtonV3>
+  );
+};
+
+const [announcement, setAnnouncement] = useState('');
+
+const onFiltersChange = useCallback(
+  (newFilters) => {
+    dispatch(setFilters(newFilters));
+    dispatch(setFilteredData(applyOutOfTheBoxFilters(originalData, newFilters)));
+  },
+  [originalData],
+);
+
+const handleClearFilters = useCallback(() => {
+  onFiltersChange([]);
+  setAnnouncement('All filters cleared');
+}, [onFiltersChange]);
+
+const ctxValue = useMemo(() => ({ filters, onClearFilters: handleClearFilters }), [filters, handleClearFilters]);
+
+<FilterBarAddonContext.Provider value={ctxValue}>
+  <ScreenReaderOnly aria-live="polite">{announcement}</ScreenReaderOnly>
+  <DataTable
+    columns={columns}
+    data={filteredData}
+    height={500}
+    withFilterBar
+    filters={filters}
+    filterBarProps={{ filterBarAddonRenderer: FilterBarAddon }}
+    onFiltersChange={onFiltersChange}
+  />
+</FilterBarAddonContext.Provider>;
+```
+
+## Common Mistakes
+
+### CRITICAL Using V1 filter string literals in new or existing code
+
+Wrong:
+
+```jsx
+{ Header: 'Position', accessor: 'position', filter: FILTER_TYPES.MULTI_SELECT }
+{ Header: 'Status', accessor: 'status', filter: FILTER_TYPES.SELECT }
+```
+
+Correct:
+
+```jsx
+{ Header: 'Position', accessor: 'position', filter: FILTER_TYPES.MULTI_SELECT_V2 }
+{ Header: 'Status', accessor: 'status', filter: FILTER_TYPES.SELECT_V2 }
+```
+
+V1 filter types are not a11y safe. When found in existing code, migrate all instances — not just the one in scope.
+
+Source: https://dimsum.mortgagetech.ice.com/iframe.html?id=components-datatable-features-filtersv2--multi-select-filter-vs-multi-select-v-2
+
+---
+
+### HIGH withFilterBar without the filters + onFiltersChange controlled pair
+
+Wrong:
+
+```jsx
+<DataTable columns={columns} data={rows} height={500} withFilterBar />
+```
+
+Correct:
+
+```jsx
+<DataTable
+  columns={columns}
+  data={filteredData}
+  height={500}
+  withFilterBar
+  filters={filters}
+  onFiltersChange={onFiltersChange}
+/>
+```
+
+`withFilterBar` only renders the UI. Without `filters` and `onFiltersChange`, filter interactions produce no result.
+
+Source: https://dimsum.mortgagetech.ice.com/iframe.html?id=components-datatable-features-filtersv2--multi-select-filter-v-2
+
+---
+
+### HIGH onFiltersChange updates filter state but does not produce updated data
+
+DataTable does not filter data internally. `onFiltersChange` receives the new filter state — the app is entirely responsible for producing the updated `data` array that reflects those filters. Storing the filters without updating `data` leaves the table showing stale rows regardless of what the user selects.
+
+**Before writing the filtering logic, determine which filtering model applies:**
+
+**Server-side / API-based filtering** — the standard model for any non-trivial dataset. On filter change, dispatch the new filter state and trigger an API call with the filters as query parameters. The response is the filtered dataset.
+
+```jsx
+const onFiltersChange = useCallback((newFilters) => {
+  dispatch(setFilters(newFilters));
+  dispatch(fetchFilteredData(newFilters)); // API call with filters as query params
+}, []);
+```
+
+**Client-side filtering** — only appropriate for very small datasets or as a temporary workaround while backend filtering endpoints are being developed. Triple-check that this is actually the correct model before implementing. Filtering is by industry standards a backend concern — backends have specialized tools for it (SQL WHERE clauses, database engine algorithms optimized for exactly this problem). Implementing it on the frontend duplicates that concern on the wrong layer with inferior tools, making the flow suboptimal and fragile. Applying filters to an in-memory array is better than offering no filtering at all, but it covers a backend limitation rather than solving the underlying problem. It also introduces stale data risk: the in-memory array reflects the dataset at load time; if the source changes and the array is never refreshed, users are filtering a snapshot, not the live data. Server-side filtering inherently avoids this because every request fetches fresh data from the authoritative source. The cost compounds further when combined with sorting and pagination.
+
+```jsx
+// Only use applyOutOfTheBoxFilters when client-side filtering is confirmed correct
+const onFiltersChange = useCallback(
+  (newFilters) => {
+    dispatch(setFilters(newFilters));
+    dispatch(setFilteredData(applyOutOfTheBoxFilters(originalData, newFilters)));
+  },
+  [originalData],
+);
+```
+
+Source: https://dimsum.mortgagetech.ice.com/iframe.html?id=components-datatable-features-filtersv2--multi-select-filter-v-2
+
+---
+
+### HIGH Non-primitive filtering props not memoized cause unnecessary re-renders
+
+Every non-primitive prop passed to DataTable must be a stable reference. For filtering, the props that require memoization are:
+
+| Prop                                  | Type      | Memoization                            |
+| ------------------------------------- | --------- | -------------------------------------- |
+| `onFiltersChange`                     | callback  | `useCallback`                          |
+| `filterBarProps`                      | object    | `useMemo` (if constructed inline)      |
+| `filterOptions` on column definitions | array     | `useMemo` on the columns array         |
+| `filterBarAddonRenderer`              | component | defined at module level — never inline |
+
+Non-stable references cause DataTable to re-render on every parent render cycle regardless of whether filtering state actually changed. `filterBarAddonRenderer` is covered in detail in the `filterBarProps` pattern above.
+
+Source: https://dimsum.mortgagetech.ice.com/iframe.html?id=components-datatable-features-filtersv2--multi-select-filter-v-2
+
+---
+
+### HIGH Tension: custom Cell renderers and filter display diverge
+
+V2 filter types derive display values from the raw data value in each cell. Custom Cell renderers change the display layer independently — the filter system has no visibility into what the custom renderer shows. Agents adding filters to columns with custom cells often produce tables where filter pills and cell display are inconsistent.
+
+When a column uses a custom Cell renderer, `applyOutOfTheBoxFilters` is no longer sufficient — it operates on raw data values and cannot account for the transformed presentation the renderer produces. The application is responsible for implementing its own filtering logic for those columns, using the IoC patterns DataTable exposes (`onFiltersChange` callback, `filters` controlled state). The OOB filter algorithms are designed to cover standard data-value scenarios only; anything beyond that is the application's domain.
+
+See also: ds-data-table-migration/SKILL.md — V1 to V2 migration patterns
+See also: ds-filter-bar-setup/SKILL.md — full DSFilterBar assembly with @elliemae/ds-filter-bar primitives
+
+---
+
+## When this isn't enough
+
+If the documented patterns cannot satisfy the requirement, contact the Dimsum team:
+
+**ICE internal:** Microsoft Teams — Dimsum channel (informal) / Jira Dimsum board (formal)
+**Partners:** Your organization's Dimsum point of contact

package/skills/ds-data-table-health-check/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: ds-data-table-health-check
+description: >
+  Audit the current state of a @elliemae/ds-data-table implementation. Use before
+  starting a task that depends on DataTable, mid-task to verify a foundation before
+  building on it, or when diagnosing unexpected behavior. Produces a complete state
+  report: what is correct and sound, what requires fixing, what is suboptimal, and
+  what gaps may affect the current task.
+type: health-check
+library: ds-data-table
+library_version: '3.60.0'
+requires:
+  - ds-data-table-setup
+  - ds-data-table-slots
+  - ds-data-table-selection
+  - ds-data-table-filtering
+  - ds-data-table-columns
+  - ds-data-table-pagination
+  - ds-data-table-expandable
+  - ds-data-table-row-variants
+  - ds-data-table-feedback
+  - ds-data-table-boundaries
+---
+
+## Purpose
+
+This skill audits an existing DataTable implementation. It is not a setup guide — it does not tell you how to build a DataTable. It tells you the current state of one that already exists.
+
+**Use it:**
+
+- Before starting a task that heavily involves a DataTable — to understand what you are about to touch before you touch it
+- Before making a DataTable load-bearing for a new feature — to verify the foundation is sound
+- When something is behaving unexpectedly — to surface what the implementation gets wrong
+
+The output is a prioritized state report. A clean report means you can proceed with confidence. A report with critical issues means fix those before doing anything else.
+
+---
+
+## Load the embedded knowledge
+
+Load the following skills **as reference knowledge only**. You are reading their embedded understanding of correct patterns — their Common Mistakes, practically mandatory props, and OOB-first guidance become the diagnostic lens. You are not running them as tasks. Do not execute any setup or implementation step from these skills.
+
+- `ds-data-table-setup` — required props, state management, a11y baseline, height/uniqueRowAccessor/domIdAffix requirements
+- `ds-data-table-slots` — slot injection surface, OOB-first hierarchy, event listener red flags
+- `ds-data-table-selection` — auto-injection model, cross-page selection, selectedControl behavior
+- `ds-data-table-filtering` — V1 vs V2 filter types, withFilterBar requirements, applyOutOfTheBoxFilters scope
+- `ds-data-table-columns` — column config, sort/resize callbacks, custom Cell escalation path
+- `ds-data-table-pagination` — Pagination render prop vs deprecated lowercase, data slicing responsibility
+- `ds-data-table-expandable` — tableRowDetails deprecation, controlled pair requirement, uniqueRowAccessor dependency
+- `ds-data-table-row-variants` — getRowVariant + data format dual requirement, groupBy utility
+- `ds-data-table-feedback` — height constraint for skeleton, isLoading vs isSkeleton distinction
+- `ds-data-table-boundaries` — useWholeStore smell, DataTable-as-form prohibition
+
+---
+
+## Procedure
+
+### Step 1 — Locate and read the implementation
+
+Find every file where `DataTable` from `@elliemae/ds-data-table` is rendered. For each instance:
+
+- Read the full props being passed
+- Read every callback handler wired to the DataTable
+- Read where the state driving the DataTable lives (state manager slice, store, atoms, or — a finding in itself — `useState`)
+- Read any column definitions, especially `Cell` and `Header` as component references
+- Note any slot props (`dsDatatableCellsContainer`, `dsDatatableCell`, `dsDatatableRow`, `dsDatatableHeadTh`)
+- Note if `renderRowActions` is present
+- Note if `withFilterBar`, `filters`, `onFiltersChange` are present
+- Note if `selection`, `onSelectionChange`, `selectSingle` are present
+- Note if `isExpandable`, `expandedRows`, `onRowExpand` are present
+- Note if `Pagination` (capital P) or `pagination` (lowercase) is present
+
+### Step 2 — Apply the diagnostic checks
+
+Work through the following checks. For each finding, assign a severity:
+
+**CRITICAL** — prevents correct function, a11y failure, or silent data corruption; fix before proceeding  
+**HIGH** — meaningful risk of regression, wrong behavior, or performance degradation  
+**MEDIUM** — suboptimal but not immediately breaking  
+**SOUND** — correct; note it so you know what you can rely on
+
+#### Foundation checks (from ds-data-table-setup)
+
+- [ ] `height` is a numeric pixel value — non-px silently defeats virtualization and scroll
+- [ ] `uniqueRowAccessor` is present when selection, expand, or drag & drop is used
+- [ ] `dsDataTableTableWrapper={{ 'aria-label': '...' }}` is present — absence is a WCAG 4.1.2 VPAT failure
+- [ ] `domIdAffix` is an explicit string when multiple DataTable instances coexist on the page
+- [ ] All DataTable-driving state lives in the project's state manager — not `useState`
+- [ ] No `useEffect` watches DataTable callback-driven state to trigger secondary logic
+
+#### Column checks (from ds-data-table-columns)
+
+- [ ] Column `width` values are pixel numbers — non-px is unsupported
+- [ ] `isResizeable` is not combined with `colsLayoutStyle='auto'` — incompatible
+- [ ] `onColumnSort` is used, not deprecated `onColumnSortChange`
+- [ ] `onColumnSizeChange` is used, not deprecated `onColumnResize`
+- [ ] Columns using `Cell` as a React component: flag each one — was OOB or slot injection considered first?
+
+#### Selection checks (from ds-data-table-selection)
+
+- [ ] `selection` prop is present — DataTable auto-injects the checkbox column when truthy; `multiSelectColumn` import is for customization only
+- [ ] `onSelectionChange` is present when `selection` is present — without it, selection silently does nothing
+- [ ] `uniqueRowAccessor` is set — without it, selection maps to wrong rows
+- [ ] Select-all cross-page: if `selectedControl === 'All'` and the dataset is paginated, is `newSelection` being merged with existing selection rather than replacing it?
+
+#### Filtering checks (from ds-data-table-filtering)
+
+- [ ] All `column.filter` values use `FILTER_TYPES.*_V2` — V1 strings are a11y-unsafe legacy
+- [ ] `withFilterBar={true}` is accompanied by both `filters` and `onFiltersChange` — either alone silently does nothing
+- [ ] `applyOutOfTheBoxFilters` is used only for client-side filtering of small datasets — not as the default model for any non-trivial dataset
+- [ ] Columns with custom `Cell` renderers that also have filters: flag — `applyOutOfTheBoxFilters` operates on raw data values, not on what the custom renderer displays
+
+#### Pagination checks (from ds-data-table-pagination)
+
+- [ ] Capital-P `Pagination` render prop is used — lowercase `pagination` prop is deprecated
+- [ ] `TablePagination` is defined at module level — not inside the component body
+- [ ] `data` passed to DataTable is the current page slice — DataTable does not paginate internally
+- [ ] Page index resets to 1 on filter change where applicable
+
+#### Expandable checks (from ds-data-table-expandable)
+
+- [ ] `tableRowDetails` is not used — deprecated; WCAG violations; propose page-level alternative
+- [ ] `expandedRows` and `onRowExpand` are both present when `isExpandable` is set
+- [ ] `uniqueRowAccessor` is set — required for expand state stability
+
+#### Slot checks (from ds-data-table-slots)
+
+- [ ] Any `dsDatatableCellsContainer` or `dsDatatableCell` callbacks: confirm they return plain props objects with no hooks inside
+- [ ] Any `dsDatatableCellsContainer` or `dsDatatableCell` callbacks: are event listeners (`onClick`, `onKeyDown`) being injected? **Flag as HIGH** — an OOB callback should handle the interaction; if not, stop and surface to the human in the loop before proceeding
+- [ ] All slot callbacks are wrapped in `useCallback`
+- [ ] `aria-*` and `data-*` injections target `CELL_CONTAINER` (`dsDatatableCellsContainer`), not `ROW` (`dsDatatableRow`) — injecting into ROW is a silent a11y failure
+
+#### Feedback checks (from ds-data-table-feedback)
+
+- [ ] `isSkeleton` is preferred over `isLoading` for initial data fetch
+- [ ] `noResultsButtonLabel` and `onNoResultsButtonClick` are either both present or both absent — either alone has no visible effect
+- [ ] If `isSkeleton` is used, `height` is a numeric pixel value — non-px silently prevents skeleton rows from rendering
+
+#### Boundary checks (from ds-data-table-boundaries)
+
+- [ ] No call to `useWholeStore()` — it re-renders on any change anywhere; use CellRendererProps IoC arguments instead
+- [ ] DataTable is not being used to drive full form data entry — use `@elliemae/ds-grid` for that
+
+---
+
+### Step 3 — Produce the state report
+
+Organize findings into four sections:
+
+**Foundation — what is correct and sound**
+List what the implementation gets right. Be specific. This is what you can rely on when making changes.
+
+**Critical issues — fix before proceeding**
+Each item with the specific prop, file, and line where the problem is. Link back to the relevant skill section for the fix.
+
+**Warnings — should address, not blocking**
+Each item with context on the risk. Note whether it is a quick fix or requires design discussion.
+
+**Awareness — no action, but good to know**
+Suboptimal patterns that are not breaking but may become relevant as the task evolves.
+
+**Gaps relevant to this task**
+Based on what the current task requires, are there missing props or wiring that will be needed? Surface these now rather than mid-implementation.
+
+---
+
+## What this skill does NOT do
+
+- It does not generate or modify code
+- It does not run the setup skills as tasks
+- It does not replace human judgment on trade-offs — critical issues are surfaced, not automatically fixed
+- It does not test the component — use the slot contract tests and compliance tests for that