{t(\"errors.fileTooLarge\", { maxSizeMB: \"10MB\" })}
\n```\n\nIn `locales/en.json` (and **every** other locale file):\n\n```json\n\"errors.fileTooLarge\": \"The file size is too large. Please select a file smaller than {{maxSizeMB}}.\"\n```\n\nFor the non-English locales, write a real translation when confident; if not, add the key with the English value and flag it in the PR — a present-but-untranslated key is visible and searchable, a missing key is invisible.\n\n## Rules that prevent real bugs\n\n- **Don't concatenate translated fragments** (`t(\"a\") + name + t(\"b\")`) — word order differs across languages. Use one key with interpolation: `t(\"greeting\", { name })`.\n- **Don't put JSX/HTML inside translation strings**; compose in JSX around `t()` calls (see how `crash.descriptionBefore` / `crash.githubIssues` / `crash.descriptionAfter` split around a link).\n- **Plurals**: use i18next plural forms (`_one` / `_other` suffixes), not `count === 1 ? ... : ...`.\n- **Keys are code**: renaming or deleting a key means updating **all seven** locale files — an orphan key in one file is dead weight; a rename missed in one file is a regression.\n- Dates/numbers/currency: format with `Intl.*` using the active locale, never hardcoded formats.\n\n## Review checklist (apply to any diff with UI text)\n\n- [ ] No hardcoded user-facing string in JSX (including `placeholder`, `title`, `aria-label`, toast/error text).\n- [ ] Every new key exists in **all** locale files (grep the key across `src/frontend/src/locales/*.json`).\n- [ ] No concatenation of translated fragments; interpolation used instead.\n- [ ] Removed/renamed keys cleaned up in all locales (no orphans).\n- [ ] Key follows the existing dot-namespace of the feature area.\n\nQuick check for a key across locales:\n\n```bash\nfor f in src/frontend/src/locales/*.json; do grep -L '\"my.new.key\"' \"$f\"; done\n```\n\n(prints the locale files where the key is **missing** — should print nothing)\n",".agents/skills/frontend-code-review/SKILL.md":"---\nname: frontend-code-review\ndescription: \"Review frontend code (.tsx, .ts, .js files) for quality, performance, and correctness against Langflow's frontend conventions. Supports pending-change reviews and file-targeted reviews.\"\n---\n\n# Frontend Code Review\n\n## When to use this skill\n\nUse this skill whenever the user asks to **review, analyze, or improve** frontend code (`.tsx`, `.ts`, `.js` files) under the `src/frontend/` directory. Supports the following review modes:\n\n1. **Pending-change review** -- inspect staged or working-tree files slated for commit and flag checklist violations before submission.\n2. **File-targeted review** -- review the specific file(s) the user names and report the relevant checklist findings.\n\nDo NOT use this skill when:\n\n- The request is about backend code (`.py` files under `src/backend/`).\n- The user is not asking for a review/analysis/improvement of frontend code.\n- The scope is outside `src/frontend/` (unless the user explicitly asks to review frontend-related changes elsewhere).\n\n## How to use this skill\n\nFollow these steps when using this skill:\n\n1. **Identify the review mode** (pending-change vs file-targeted) based on the user's input. Keep the scope tight: review only what the user provided or explicitly referenced.\n2. Follow the rules defined in the **Checklist** to perform the review. If no checklist rule matches, apply **General Review Rules** as a fallback.\n3. Compose the final output strictly following the **Required Output Format**.\n\nNotes when using this skill:\n\n- Always include actionable fixes or suggestions (including possible code snippets).\n- Use `File:Line` references when a file path and line numbers are available; otherwise, use the most specific identifier you can.\n- The Langflow frontend uses React 19, TypeScript 5.4, Vite 7 with SWC, Zustand for state management, TanStack React Query for server state, @xyflow/react v12 for graph visualization, Radix UI + shadcn-ui components, Tailwind CSS v3, and Biome for linting/formatting.\n\n## Checklist\n\n- **Code quality**: For any reviewed file, follow [references/code-quality.md](references/code-quality.md) to check styling conventions, TypeScript usage, Biome compliance, and component patterns.\n- **Performance**: If the review scope involves React components, hooks, Zustand stores, React Query usage, or @xyflow/react node rendering, follow [references/performance.md](references/performance.md) to check for re-render issues, memoization, and data flow patterns.\n- **Business logic**: If the review scope involves custom nodes (GenericNode), flow state, API calls, the component system, global variables, or the inspection panel, follow [references/business-logic.md](references/business-logic.md) to check for Langflow-specific correctness.\n- **i18n**: If the diff adds or changes user-facing text (labels, buttons, tooltips, modals, toasts, errors, placeholders, aria-labels), follow the [frontend-i18n skill](../frontend-i18n/SKILL.md): no hardcoded UI strings — everything through `t(...)` — and every new key present in **all** locale files (`src/frontend/src/locales/*.json`).\n\n## General Review Rules\n\n### 1. Security Review\n\nCheck for:\n- XSS vulnerabilities (dangerouslySetInnerHTML, unescaped user input)\n- Sensitive data exposure in client-side code\n- Insecure direct object references in API calls\n- Hardcoded secrets, tokens, or API keys\n\n### 2. Accessibility Review\n\nCheck for:\n- Missing aria labels on interactive elements\n- Keyboard navigation support\n- Proper use of semantic HTML elements\n- Color contrast issues in custom styling\n\n### 3. Code Quality Review\n\nCheck for:\n- Code duplication (DRY violations — extract at 3+ identical usages)\n- Functions/components doing too much (SRP violations — if you need \"and\" to describe it, split it)\n- Deep nesting or complex conditionals (prefer early returns and guard clauses)\n- Magic numbers/strings without named constants\n- Poor naming: generic names (`data`, `result`, `temp`), missing verb prefixes on functions, missing `is`/`has`/`can`/`should` prefixes on booleans\n- Missing error handling or error boundaries\n- Incomplete TypeScript type coverage (no `any`, no `as any` casts)\n- Comments that explain WHAT instead of WHY\n- Commented-out code (use version control)\n- Boolean parameters that switch component behavior (use two components instead)\n- Mutable patterns where `const` or immutable alternatives exist\n- Production files exceeding ~500 lines (red flag at 600+)\n- `console.log` in production code (Biome flags this)\n\n### 4. Testing Impact Review\n\nCheck for:\n- Changes to data-testid attributes that may break E2E tests\n- Modified component interfaces that require test updates\n- New interactive elements missing data-testid attributes\n\n### 5. Pre-Commit Verification\n\nFor pending-change reviews, verify:\n- `npm run format` (Biome formatter) — zero diffs\n- `npm run lint` (Biome linter) — zero errors\n- `npm test` (Jest) — zero failures\n\n## Required Output Format\n\nWhen this skill is invoked, the response must exactly follow one of the two templates:\n\n### Template A (any findings)\n\n```markdown\n# Code Review\n\nFound (optional, omit if not applicable)\n\n---\n... (repeat for each critical issue) ...\n\nFound suggestions for improvement:\n\n## 🟡 Suggestions (Should Consider)\n\n### 1. \n\nFilePath: line \n\n\n#### Explanation\n\n\n\n#### Suggested Fix\n\n1. \n2. (optional, omit if not applicable)\n\n---\n... (repeat for each suggestion) ...\n\nFound optional nits:\n\n## 🟢 Nits (Optional)\n### 1. \n\nFilePath: line \n\n\n#### Explanation\n\n\n\n#### Suggested Fix\n\n- \n\n---\n... (repeat for each nits) ...\n\n## ✅ What's Good\n\n- \n```\n\n- If there are no critical issues or suggestions or optional nits or good points, just omit that section.\n- If the issue number is more than 10, summarize as \"Found 10+ critical issues/suggestions/optional nits\" and only output the first 10 items.\n- Don't compress the blank lines between sections; keep them as-is for readability.\n- If there is any issue that requires code changes, append a brief follow-up question to ask whether the user wants to apply the fix(es) after the structured output. For example: \"Would you like me to use the Suggested fix(es) to address these issues?\"\n\n### Template B (no issues)\n\n```markdown\n## Code Review Summary\n✅ No issues found.\n```\n",".agents/skills/frontend-testing/SKILL.md":"# Frontend Testing Skill - Langflow\n\n## When to Apply\n\nActivate this skill when:\n- Writing new unit or integration tests for React components, hooks, utilities, or Zustand stores\n- Reviewing existing tests for correctness, coverage, or best practices\n- Improving test coverage for under-tested modules\n- Debugging flaky or failing tests\n- Refactoring test code for maintainability\n\n## Tech Stack\n\n| Technology | Version | Purpose |\n|---|---|---|\n| Jest | 30.x | Test runner and assertion framework |\n| ts-jest | 29.x | TypeScript transform for Jest |\n| React Testing Library | 16.x | Component rendering and DOM queries |\n| @testing-library/user-event | 14.x | Realistic user interaction simulation |\n| @testing-library/jest-dom | 6.x | Extended DOM matchers |\n| jsdom | (via jest-environment-jsdom 30.x) | Browser environment simulation |\n| React | 19.x | UI framework |\n| TypeScript | 5.4 | Type safety |\n| Zustand | 4.x | State management |\n| React Router DOM | 6.x | Client-side routing |\n| @tanstack/react-query | 5.x | Server state management |\n| Axios | 1.x | HTTP client |\n\n## Project Configuration\n\n- **Jest config**: `src/frontend/jest.config.js`\n- **Setup files**: `src/frontend/jest.setup.js` (globals/mocks) and `src/frontend/src/setupTests.ts` (DOM matchers, ResizeObserver, IntersectionObserver, matchMedia)\n- **Path alias**: `@/` maps to `/src/`\n- **Test match patterns**: `src/**/__tests__/**/*.{test,spec}.{ts,tsx}` and `src/**/*.{test,spec}.{ts,tsx}`\n- **Transform**: Custom `transform-import-meta.js` handles `import.meta` for Jest compatibility\n- **Global mocks** (in `jest.setup.js`): `@radix-ui/react-form`, `react-markdown`, `remark-gfm`, `remark-math`, `rehype-mathjax/browser`, `lucide-react/dynamicIconImports`, `@/components/common/genericIconComponent`, `@/icons/BotMessageSquare`, `@/stores/darkStore`, `localStorage`, `sessionStorage`, `crypto`\n\n## Key Commands\n\n```bash\n# Run all tests\nnpm test\n\n# Run a specific test file\nnpm test -- path/to/file.test.tsx\n\n# Run tests matching a pattern\nnpm test -- --testPathPattern=\"alertStore\"\n\n# Run tests in watch mode\nnpm run test:watch\n\n# Run tests with coverage\nnpm run test:coverage\n\n# Run a single test file with coverage\nnpm test -- --coverage --collectCoverageFrom='src/path/to/source.ts' path/to/__tests__/source.test.ts\n```\n\n## File Naming and Location\n\nTest files follow one of two patterns:\n\n1. **Dedicated `__tests__` directory** (preferred for components and modules):\n ```\n src/components/core/my-component/\n ├── my-component.tsx\n └── __tests__/\n └── my-component.test.tsx\n ```\n\n2. **Co-located test file** (acceptable for utilities and simple modules):\n ```\n src/utils/\n ├── myUtil.ts\n └── myUtil.test.ts\n ```\n\nNaming convention: `ComponentName.test.tsx` for components, `hook-name.test.ts` for hooks, `util-name.test.ts` for utilities.\n\n**Do NOT use `.spec.tsx`** -- while technically matched, the project convention is `.test.tsx`.\n\n## Test Structure Template\n\n```tsx\nimport { render, screen } from \"@testing-library/react\";\nimport userEvent from \"@testing-library/user-event\";\nimport MyComponent from \"../MyComponent\";\n\n// Mock dependencies (use jest.mock, NOT vi.mock)\njest.mock(\"@/controllers/API/api\", () => ({\n get: jest.fn(),\n post: jest.fn(),\n}));\n\ndescribe(\"MyComponent\", () => {\n beforeEach(() => {\n jest.clearAllMocks();\n });\n\n describe(\"rendering\", () => {\n it(\"should render the component with default props\", () => {\n // Arrange\n render(.a11y.spec.ts --project=chromium --workers=5\n\n# Optional: HTML triage report\nnpm run a11y:html-report --silent\n# → coverage/accessibility-reports/index.html\n\n# Ad-hoc route batch (default-loaded page only) — see ibm-a11y-route-scan for details\nuv run --with playwright python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes-file scripts/a11y/a11y_routes.json \\\n --route-group static \\\n --out /tmp/langflow-a11y.json \\\n --markdown /tmp/langflow-a11y.md \\\n --html /tmp/langflow-a11y.html \\\n --timeout-ms 45000\n```\n\nFor component-only changes, also run Jest axe where a `__tests__/*.a11y.test.tsx` exists.\n\nDo not invent findings. Prefer scanner output + manual Level 1 checks scanners miss (keyboard trap both directions, focus restore, reflow at 320px, color-not-only cues).\n\n### 3. Map findings to Level 1\n\nFor each issue, assign:\n\n- **WCAG / IBM ID** from [references/ibm-level1-criteria.md](references/ibm-level1-criteria.md) (e.g. `2.1.1`, `4.1.2`)\n- **IBM ruleId** when from Equal Access (`aria_accessiblename_exists`, `element_tabbable_role_valid`, …)\n- **Severity:** `violation` | `potentialviolation` | `manual`\n- **In scope?** Drop or defer anything listed under **Deferred to Level 2 & Level 3** in the criteria doc unless the user expands scope.\n\n### 4. Write the report\n\nUse [references/report-template.md](references/report-template.md). Deliver the report in the chat (and write a file only if the user asks for a path).\n\nRequired sections: Summary, Scope, Findings table, Fixes applied / proposed, Verification, Remaining risk / baselines.\n\n**Stop here by default.** List proposed fixes in the report without editing files, unless the user's request explicitly also asked for remediation (e.g. \"audit and fix\", \"fix what you find\"). If they only asked for an audit or report, do not proceed to step 5.\n\n### 5. Fix violations (only when explicitly requested)\n\nOnly continue past the report if the user's request explicitly asked for fixes alongside the audit. Otherwise stop after step 4.\n\n- Prefer semantic HTML over ARIA.\n- Follow Langflow patterns in `ibm-a11y-testing-guide` (AG Grid, Radix `asChild`, focus restore, icon-only `aria-label`).\n- Route new UI strings / `aria-label`s through `frontend-i18n`.\n- Do **not** silently disable scans. Use IBM baselines under `src/frontend/tests/a11y/baselines/` only for documented framework debt (see `ibm-a11y-testing-guide`).\n- Keep fixes minimal; do not refactor unrelated UI.\n\n### 6. Verify with `tests/a11y`\n\nConfirm path: `src/frontend/tests/a11y/`.\n\n| Surface | Spec to run / update |\n|---------|----------------------|\n| Static routes | `static-routes.a11y.spec.ts` (+ `scripts/a11y/a11y_routes.json` if new route) |\n| Auth | `auth-pages.a11y.spec.ts` |\n| Core pages | `core-pages.a11y.spec.ts` |\n| Data-rich (files, API keys, globals) | `files.a11y.spec.ts`, `api-keys.a11y.spec.ts`, `global-variables.a11y.spec.ts` |\n| Other data-rich | `data-rich-routes.a11y.spec.ts` |\n| Baselines | `baselines/*.json` |\n\nCommands:\n\n```bash\ncd src/frontend\nRUN_A11Y=true RUN_A11Y_ASSERT=true npx playwright test tests/a11y/.a11y.spec.ts --project=chromium --workers=5\n```\n\nIf coverage is missing for a fixed state, add a scan (and keyboard test when custom keyboard behavior was fixed) following `files.a11y.spec.ts` / `api-keys.a11y.spec.ts` patterns.\n\n### 7. Close the loop\n\nRe-run the same scans. Update the report: each finding → `fixed` | `baselined` | `open`. State commands run and whether IBM assert mode passed.\n\n## Manual Level 1 spot checks\n\nScanners miss some Level 1 tasks — spot-check when relevant:\n\n- **2.1.1 / 2.1.2:** Tab and Shift+Tab through the surface; Escape closes overlays; no trap.\n- **2.4.3 / 2.4.7:** Focus order matches visual order; focus ring visible.\n- **1.4.10:** 320px width / ~400% zoom — no essential horizontal scroll.\n- **1.4.1:** Status/errors not color-only.\n- **3.3.1 / 3.3.2:** Errors named in text and tied to fields; inputs labeled.\n\n## Best practices (data grids + modals)\n\nWhen auditing **settings tables** (especially `/settings/global-variables`) and similar AG Grid + modal flows, treat these as Level 1 best practices (2.1.1 / 2.4.3) — not edge-case gotchas.\n\n### Selectable-row keyboard map\n\nReference implementation: `GlobalVariablesPage` + `tests/a11y/global-variables.a11y.spec.ts`.\n\n| Key | Behavior |\n|-----|----------|\n| **Space** | Toggle the row selection checkbox (do **not** open edit) |\n| **Enter** | Open the Update Variable modal for the focused row |\n\nImplementation notes:\n\n- Handle in page-level `onCellKeyDown` only (do not change shared `TableComponent` defaults for other grids unless the product asks for the same map).\n- Add `suppressKeyboardEvent` on that page’s column defs for Enter/Space so AG Grid’s built-in Space selection does not fight the custom handler.\n- Sync React selection state after `node.setSelected` so toolbar delete enablement updates (`TableOptions.hasSelection` is read at render time).\n\n### Modal open/close — retain last position (focus restore)\n\n- Opening edit from a row/cell must remember the focused cell (`rowIndex` + `colId`).\n- Closing the edit modal (Escape, Cancel, or successful save) must restore focus to that same cell via `api.setFocusedCell` + DOM `.focus()`, using a few `requestAnimationFrame`s to outlast Radix dialog focus cleanup.\n- Create modal opened from **Add New** should restore to that trigger (Radix default when a real `DialogTrigger` exists).\n- Verify with a Playwright keyboard test: open from a cell → Escape → `document.activeElement` is still that cell (or its `col-id`), then Enter can open again without a manual mouse re-focus.\n\nFor AG Grid pagination/tab traps, Radix `asChild`, and popover Esc restore details, see [ibm-a11y-testing-guide](../ibm-a11y-testing-guide/SKILL.md) (Gotchas vs Best practices sections).\n\n## Out of scope (unless asked)\n\n- IBM Level 2/3 criteria listed as deferred in the criteria reference\n- Section 508 software-only rows (web UI covered via 4.1.2)\n- Media captions (1.2.x) when the surface has no audio/video\n- Fixing violations without an explicit remediation request (report only by default)\n",".agents/skills/ibm-a11y-route-scan/SKILL.md":"---\nname: ibm-a11y-route-scan\ndescription: Batch-scan Langflow frontend routes for accessibility issues using the Python IBM Equal Access scanner (scripts/a11y/a11y_scan.py) and produce JSON/Markdown/HTML reports. Scans the default-loaded state of each route only (use explicit state files for modals). Use when asked to scan one or more routes, produce an accessibility report for pages, or batch-check static routes. Reports findings only — does not fix code, run Playwright/axe tests, or perform a formal Level 1 audit; see ibm-a11y-testing-guide, ibm-a11y-level1-audit, and ibm-a11y-pr-remediation for those.\n---\n\n# IBM Route Scanner\n\nUse this skill when asked to scan Langflow frontend pages for accessibility issues with the local Python scanner. This skill only reports — it does not modify code. For test-writing guidance, formal audits, or PR-wide fixes, see `ibm-a11y-testing-guide`, `ibm-a11y-level1-audit`, and `ibm-a11y-pr-remediation`.\n\n## Scanner\n\nUse the Python script:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes-file scripts/a11y/a11y_routes.json \\\n --route-group static \\\n --out /tmp/langflow-a11y-report.json \\\n --markdown /tmp/langflow-a11y-report.md \\\n --html /tmp/langflow-a11y-report.html \\\n --timeout-ms 45000\n```\n\nScript options:\n\n- `--url`: base app URL, usually `http://localhost:3000`.\n- `--routes-file`: route manifest JSON file. Prefer `scripts/a11y/a11y_routes.json`.\n- `--route-group`: manifest group to scan. Default: `static`.\n- `--routes`: comma-separated route paths to scan.\n- `--route`: one route path; can be repeated instead of `--routes`.\n- `--levels`: comma-separated issue levels. Default: `violation`.\n- `--out`: JSON report path.\n- `--markdown`: optional Markdown report path.\n- `--html`: optional self-contained HTML report path.\n- `--timeout-ms`: per-route timeout.\n- `--quiet-ms`: network quiet window before scanning. Default: `1000`.\n- `--states-file`: JSON file with explicit modal/state actions.\n- `--headed`: show browser while scanning.\n\n## Route Selection\n\nUse `scripts/a11y/a11y_routes.json` as the source of truth for route selection.\n\nThe normal CI/local batch is the manifest `static` group. Prefer that unless the user asks for custom, dynamic, or gated routes.\n\nCommon manifest-backed command:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes-file scripts/a11y/a11y_routes.json \\\n --route-group static \\\n --out /tmp/langflow-a11y-static.json \\\n --markdown /tmp/langflow-a11y-static.md \\\n --html /tmp/langflow-a11y-static.html\n```\n\nDynamic routes need real IDs before scanning:\n\n- `/flow/:id/`\n- `/flow/:id/view`\n- `/playground/:id/`\n- `/assets/knowledge-bases/:sourceId/chunks`\n\nFor dynamic routes, get IDs from the loaded app, API responses, or existing test data before replacing placeholders.\n\n## Examples\n\nScan one route:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --route /flows \\\n --out /tmp/langflow-a11y-flows.json\n```\n\nScan multiple routes:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes-file scripts/a11y/a11y_routes.json \\\n --route-group static \\\n --out /tmp/langflow-a11y-report.json \\\n --markdown /tmp/langflow-a11y-report.md \\\n --html /tmp/langflow-a11y-report.html\n```\n\nScan more than violations:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes-file scripts/a11y/a11y_routes.json \\\n --route-group static \\\n --levels violation,potentialviolation,recommendation \\\n --out /tmp/langflow-a11y-expanded.json\n```\n\nScan route plus modal states:\n\n```bash\nuv run python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --states-file /tmp/langflow-a11y-states.json \\\n --out /tmp/langflow-a11y-modal-report.json \\\n --markdown /tmp/langflow-a11y-modal-report.md \\\n --html /tmp/langflow-a11y-modal-report.html \\\n --timeout-ms 45000\n```\n\nState file shape:\n\n```json\n[\n {\n \"route\": \"/settings/global-variables\",\n \"states\": [\n {\n \"name\": \"new-global-variable-modal\",\n \"open\": [\n { \"click\": \"[data-testid='api-key-button-store']\" },\n { \"waitFor\": \"[role='dialog']\" }\n ],\n \"close\": [\n { \"press\": \"Escape\" },\n { \"waitForHidden\": \"[role='dialog']\" }\n ]\n }\n ]\n }\n]\n```\n\nSupported state actions:\n\n- `{ \"click\": \"\" }`\n- `{ \"clickText\": \"\" }`\n- `{ \"clickRole\": { \"role\": \"button\", \"name\": \"Create\" } }`\n- `{ \"fill\": { \"selector\": \"\", \"value\": \"text\" } }`\n- `{ \"press\": \"Escape\" }`\n- `{ \"press\": { \"selector\": \"\", \"key\": \"Enter\" } }`\n- `{ \"waitFor\": \"\" }`\n- `{ \"waitForHidden\": \"\" }`\n- `{ \"waitForText\": \"\" }`\n- `{ \"wait\": 500 }`\n- `{ \"scroll\": { \"selector\": \"\", \"to\": \"bottom\" } }` — `to` is `top` or\n `bottom`; use `\"by\": ` for a relative scroll, and omit `selector` to scroll the\n page. Needed for virtualised grids whose tabbable rows only disappear after scrolling.\n\n## Report\n\nThe scanner always writes JSON. It can also write Markdown and HTML for presentation.\n\nUse JSON for exact data. Use Markdown for PR comments or issues. Use HTML when the user wants a browsable report.\n\nSummarize:\n\n- report path\n- Markdown/HTML report paths, when generated\n- total issue count\n- per-route issue count\n- per-route API request count\n- per-route request failure count\n- top rule IDs\n\nUse report fields directly:\n\n- `totalIssues`\n- `results[].route`\n- `results[].state`\n- `results[].phase`\n- `results[].apiRequests`\n- `results[].requestFailures`\n- `results[].diagnostics`\n- `results[].issues[].ruleId`\n\n## Rules\n\n- Use only scanner output for findings.\n- Do not invent route names. Read `routes.tsx`.\n- Do not auto-click arbitrary buttons to find modals. Use explicit state actions.\n- Avoid destructive modal actions unless the user explicitly asks and data is safe.\n- If a route has zero API requests, mention that scan quality may be limited.\n- This skill reports only; do not edit files. If the user also wants fixes applied, hand off to `ibm-a11y-pr-remediation` or `ibm-a11y-level1-audit`.\n",".agents/skills/component-refactoring/SKILL.md":"---\nname: component-refactoring\ndescription: Refactor high-complexity React components in Langflow frontend. Use when manual complexity assessment shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.\n---\n\n# Langflow Component Refactoring Skill\n\nRefactor high-complexity React components in the Langflow frontend codebase with the patterns and workflow below.\n\n> **Complexity Threshold**: Components with complexity > 50 (measured manually by counting conditionals, nesting levels, and lines) should be refactored before testing.\n\n## Quick Reference\n\n### Commands (run from `src/frontend/`)\n\n```bash\ncd src/frontend\n\n# Lint with Biome\nnpm run lint\n\n# Type checking\nnpm run type-check\n\n# Run tests\nnpm test\n```\n\n### Manual Complexity Assessment\n\nSince Langflow does not have automated complexity analysis tools, assess components manually:\n\n1. **Count conditionals**: Each `if/else`, `switch/case`, ternary, `&&`/`||` chain adds +1.\n2. **Count nesting levels**: Each level of nesting within conditionals or loops adds +1.\n3. **Count total lines**: Target < 300 lines per component file.\n4. **Count state hooks**: More than 5 `useState` calls suggests hook extraction.\n5. **Count effects**: More than 3 `useEffect` calls suggests effect consolidation.\n\n### Complexity Score Interpretation\n\n| Score | Level | Action |\n|-------|-------|--------|\n| 0-25 | Simple | Ready for testing |\n| 26-50 | Medium | Consider minor refactoring |\n| 51-75 | Complex | **Refactor before testing** |\n| 76-100 | Very Complex | **Must refactor** |\n\n## Core Refactoring Patterns\n\n### Pattern 1: Extract Custom Hooks\n\n**When**: Component has complex state management, multiple `useState`/`useEffect`, or business logic mixed with UI.\n\n**Langflow Convention**: Place hooks in a `hooks/` subdirectory or alongside the component as `use-.ts`. Langflow uses kebab-case filenames with `use-` prefix.\n\n```typescript\n// Before: Complex state logic in component\nconst FlowPage: FC = () => {\n const [nodes, setNodes] = useState([])\n const [edges, setEdges] = useState([])\n const [buildStatus, setBuildStatus] = useState(BuildStatus.IDLE)\n\n // 50+ lines of state management logic...\n\n return ...\n}\n\n// After: Extract to custom hook\n// hooks/use-flow-state.ts\nexport const useFlowState = (flowId: string) => {\n const [nodes, setNodes] = useState([])\n const [edges, setEdges] = useState([])\n const [buildStatus, setBuildStatus] = useState(BuildStatus.IDLE)\n\n // Related state management logic here\n\n return { nodes, setNodes, edges, setEdges, buildStatus, setBuildStatus }\n}\n\n// Component becomes cleaner\nconst FlowPage: FC = () => {\n const { nodes, setNodes, edges, setEdges } = useFlowState(flowId)\n return ...\n}\n```\n\n**Langflow Examples**:\n- `src/frontend/src/hooks/use-add-component.ts`\n- `src/frontend/src/hooks/use-unsaved-changes.ts`\n- `src/frontend/src/hooks/use-refresh-model-inputs.ts`\n\n### Pattern 2: Extract Sub-Components\n\n**When**: Single component has multiple UI sections, conditional rendering blocks, or repeated patterns.\n\n**Langflow Convention**: Place sub-components in subdirectories or as separate files in the same directory. UI primitives go in `components/ui/`, domain components in `components/core/`, reusable components in `components/common/`.\n\n```typescript\n// Before: Monolithic JSX with multiple sections\nconst GenericNode = () => {\n return (\n \n {/* 100 lines of header UI */}\n {/* 100 lines of parameter fields */}\n {/* 100 lines of output handles */}\n \n )\n}\n\n// After: Split into focused components\n// CustomNodes/GenericNode/\n// generic-node.tsx (orchestration only — kebab-case, descriptive name)\n// components/\n// node-header.tsx\n// node-parameters.tsx\n// node-outputs.tsx\n\nconst GenericNode = () => {\n return (\n \n > = {\n int: IntComponent,\n float: FloatComponent,\n bool: ToggleComponent,\n code: CodeAreaComponent,\n}\n\nconst STR_VARIANT_MAP: Record> = {\n multiline: TextAreaComponent,\n password: PasswordInput,\n options: Dropdown,\n}\n\nconst getFieldComponent = (field: InputFieldType) => {\n if (field.type !== \"str\") {\n const Component = FIELD_COMPONENT_MAP[field.type]\n return Component ? (null)\n\n const openModal = useCallback((type: ModalType) => setActiveModal(type), [])\n const closeModal = useCallback(() => setActiveModal(null), [])\n\n return {\n activeModal,\n openModal,\n closeModal,\n isOpen: (type: ModalType) => activeModal === type,\n }\n}\n```\n\n### Pattern 6: Extract Form Logic\n\n**When**: Complex form validation, submission handling, or field transformation.\n\n**Langflow Convention**: Extract form state and validation into hooks.\n\n```typescript\n// Extract form validation and submission\nconst useFlowSettingsForm = (initialValues: FlowSettings) => {\n const [values, setValues] = useState(initialValues)\n const [errors, setErrors] = useState>({})\n\n const validate = useCallback(() => {\n const newErrors: Record = {}\n if (!values.name?.trim()) newErrors.name = \"Name is required\"\n if (values.endpoint_name && !/^[a-z0-9-]+$/.test(values.endpoint_name)) {\n newErrors.endpoint_name = \"Must be lowercase alphanumeric with hyphens\"\n }\n setErrors(newErrors)\n return Object.keys(newErrors).length === 0\n }, [values])\n\n const handleChange = useCallback((field: string, value: any) => {\n setValues((prev) => ({ ...prev, [field]: value }))\n }, [])\n\n return { values, errors, validate, handleChange }\n}\n```\n\n## Langflow-Specific Refactoring Guidelines\n\n### 1. Zustand Store Selectors\n\n**When**: Component reads many values from a Zustand store, causing unnecessary re-renders.\n\n```typescript\n// Before: Selecting too many values\nconst Component = () => {\n const flowStore = useFlowStore()\n // Component re-renders on ANY store change\n}\n\n// After: Use individual selectors\nconst Component = () => {\n const nodes = useFlowStore((state) => state.nodes)\n const edges = useFlowStore((state) => state.edges)\n // Component only re-renders when nodes or edges change\n}\n```\n\n**Langflow Reference**: All stores in `src/frontend/src/stores/` follow this selector pattern.\n\n### 2. Custom Node Components\n\n**When**: Refactoring flow node components (`CustomNodes/GenericNode/`).\n\n**Conventions**:\n- Keep node logic in custom hooks\n- Extract parameter rendering to separate components\n- Use the existing `components/` subdirectory for sub-components\n\n```\nCustomNodes/GenericNode/\n generic-node.tsx # Node registration and main render (kebab-case, NOT index.tsx)\n components/\n handle-render.tsx # Handle rendering\n node-description.tsx # Node description display\n node-input-field.tsx # Input field rendering\n node-name.tsx # Node name display\n node-output-field.tsx # Output field rendering\n node-status.tsx # Build status display\n```\n\n### 3. Flow Canvas Components\n\n**When**: Refactoring components related to the flow editor canvas.\n\n**Conventions**:\n- `@xyflow/react` v12 is the canvas library\n- Keep canvas event handlers separate from UI rendering\n- Use `useFlowStore` for flow state management\n- Use `useFlowsManagerStore` for multi-flow management\n\n### 4. API Query Hook Components\n\n**When**: Refactoring components that consume API data.\n\n**Conventions**:\n- Use existing query hooks from `controllers/API/queries/`\n- Access `UseRequestProcessor` for new queries/mutations\n- Use query key arrays like `[\"useGetGlobalVariables\"]` for cache management\n- Cache invalidation belongs in mutation `onSettled` callbacks\n\n## Refactoring Workflow\n\n### Step 1: Assess Complexity\n\nManually count:\n- Total conditionals (if/else, switch, ternary, &&/||)\n- Maximum nesting depth\n- Total lines of code\n- Number of useState/useEffect hooks\n- Number of distinct UI sections\n\n### Step 2: Plan\n\nCreate a refactoring plan based on detected features:\n\n| Detected Feature | Refactoring Action |\n|------------------|-------------------|\n| 5+ `useState` hooks with related state | Extract custom hook |\n| API calls in component body | Extract to query hook |\n| 3+ event handlers with logic | Extract event handlers to hook |\n| 300+ lines | Split into sub-components |\n| Deep conditional nesting (>3) | Simplify conditional logic |\n| Multiple modal states | Extract modal management |\n\n### Step 3: Execute Incrementally\n\n1. **Extract one piece at a time**\n2. **Run lint, type-check, and tests after each extraction**\n3. **Verify functionality before next step**\n\n```\nFor each extraction:\n 1. Extract code\n 2. Run: npm run lint\n 3. Run: npm run type-check\n 4. Run: npm test\n 5. Test functionality manually\n 6. PASS? -> Next extraction\n FAIL? -> Fix before continuing\n```\n\n### Step 4: Verify\n\nAfter refactoring, re-assess complexity manually:\n\n- Target complexity < 50\n- Target line count < 300\n- Target max nesting depth <= 3\n- Target max function length < 30 lines\n\n## Common Mistakes to Avoid\n\n### Over-Engineering\n\n```typescript\n// Too many tiny hooks\nconst useButtonText = () => useState(\"Click\")\nconst useButtonDisabled = () => useState(false)\nconst useButtonLoading = () => useState(false)\n\n// Cohesive hook with related state\nconst useButtonState = () => {\n const [text, setText] = useState(\"Click\")\n const [disabled, setDisabled] = useState(false)\n const [loading, setLoading] = useState(false)\n return { text, setText, disabled, setDisabled, loading, setLoading }\n}\n```\n\n### Breaking Existing Patterns\n\n- Follow existing directory structures in `components/ui/`, `components/core/`, `components/common/`\n- Maintain naming conventions (kebab-case files, PascalCase components)\n- Preserve export patterns for compatibility\n- Keep Zustand store selector patterns consistent\n\n### Premature Abstraction\n\n- Only extract when there is clear complexity benefit\n- Do not create abstractions for single-use code\n- Keep refactored code in the same domain area\n\n### Bypassing UseRequestProcessor\n\n- Do not call `useQuery` or `useMutation` directly for API calls\n- Always use the `UseRequestProcessor` pattern for consistency with retry and invalidation logic\n- See `frontend-query-mutation` skill for API hook patterns\n\n## References\n\n### Langflow Codebase Examples\n\n- **Hook extraction**: `src/frontend/src/hooks/`\n- **Component splitting**: `src/frontend/src/CustomNodes/GenericNode/components/`\n- **UI components**: `src/frontend/src/components/ui/`\n- **Core components**: `src/frontend/src/components/core/`\n- **Common components**: `src/frontend/src/components/common/`\n- **API query hooks**: `src/frontend/src/controllers/API/queries/`\n- **Zustand stores**: `src/frontend/src/stores/`\n\n### Related Skills\n\n- `frontend-query-mutation` - For API query and mutation patterns\n- `frontend-testing` - For testing refactored components\n",".agents/skills/ibm-a11y-testing-guide/SKILL.md":"---\nname: ibm-a11y-testing-guide\ndescription: Reference guide for writing and running Langflow frontend accessibility tests with axe (Jest) and IBM Equal Access (Playwright `page.runA11yScan`). Covers which engine/test layer to pick, the POUR checklist, axe-vs-IBM rule gaps, Radix/AG-Grid component gotchas, and IBM baselines. Use when writing or reviewing a11y tests, debugging a specific axe/IBM violation, or deciding which test layer fits a UI surface. Does not run scans, audit a whole surface, or fix a PR end-to-end — see ibm-a11y-route-scan, ibm-a11y-level1-audit, and ibm-a11y-pr-remediation for those.\n---\n\n# IBM/axe Accessibility Testing Guide\n\nReference material for **how** to test a given UI surface. This skill does not decide what to scan or drive a fix loop by itself — use it while writing tests, debugging a violation, or implementing a fix identified by `ibm-a11y-route-scan`, `ibm-a11y-level1-audit`, or `ibm-a11y-pr-remediation`.\n\n## When To Use\n\nUse this skill for frontend work under `src/frontend` when the change affects:\n\n- UI components, primitives, pages, routes, dialogs, drawers, popovers, dropdowns, tabs, accordions, tables, forms, navigation, or canvas controls.\n- ARIA attributes, labels, roles, focus management, tab order, keyboard interaction, disabled states, loading states, or error states.\n- A request to write, fix, or review an axe/IBM accessibility test.\n\nUse alongside:\n\n- `frontend-testing` for Jest/React Testing Library patterns.\n- `e2e-testing` for Playwright patterns.\n- `frontend-i18n` when adding or changing user-facing labels, accessible names, `aria-label`, tooltips, or visible strings.\n- `ibm-a11y-route-scan` to batch-scan routes with the Python scanner and produce Markdown/HTML reports.\n- `ibm-a11y-level1-audit` for a scoped IBM Level 1 compliance audit and report.\n- `ibm-a11y-pr-remediation` to scan and fix an entire PR/branch end-to-end.\n\n## Goal\n\nDo not stop at \"run axe on default render.\" Inspect the changed UI and cover every meaningful user-visible state, for both keyboard and screen-reader users, that can expose accessibility bugs.\n\n## The Bar: two engines, both must pass\n\nAutomated a11y is not one tool. Run BOTH — they catch different classes of bug:\n\n- **axe-core** — Jest `axe()` (`@/utils/a11y-test`), jsdom-only. Fast; strong on contrast, labels, roles, ARIA basics.\n- **IBM Equal Access** — the stricter engine on ARIA structure and keyboard semantics; catches real WCAG Level-1 issues axe silently passes. Two entry points, **same engine** (`aChecker`):\n - Playwright **`page.runA11yScan(label)`** — runs `aChecker.getCompliance` in-browser on the **live DOM**, so it scans open modals / menus / selected / editing states. This is IBM, **not** axe (despite the name).\n - `scripts/a11y/a11y_scan.py` (see `ibm-a11y-route-scan`) — route scanner for the default-loaded page only.\n\nA page that is green on axe is NOT done. When the change touches a table/tree/listbox/menu/composite widget, IBM is mandatory. Prefer `page.runA11yScan` for stateful surfaces (it sees the DOM after your interactions); use the Python scanner for a quick default-load route check.\n\nVerify commands:\n\n```bash\ncd src/frontend\nRUN_A11Y=true RUN_A11Y_ASSERT=true npx playwright test tests/a11y/.a11y.spec.ts --project=chromium --workers=5\n\n# The Python scanner's playwright deps are NOT in the default `uv sync`.\n# One-time: `uv run --with playwright playwright install chromium`\nuv run --with playwright python scripts/a11y/a11y_scan.py \\\n --url http://localhost:3000 \\\n --routes /settings/ \\\n --out /tmp/a11y.json --markdown /tmp/a11y.md --timeout-ms 45000\n```\n\n`RUN_A11Y=true` runs the scan; add `RUN_A11Y_ASSERT=true` to actually fail on new violations (without it the scan is informational). Both engines must report zero. After changing a shared component, re-scan every page that uses it, not just the one you touched.\n\n## First Pass\n\n1. Read the changed files and nearby tests.\n2. Identify the UI surface:\n - Primitive/component only\n - Composed component\n - Page/route\n - Stateful workflow\n - Shared helper that changes labels, roles, tab order, or focus behavior\n3. List interactive surfaces:\n - Buttons, links, inputs, checkboxes, switches, radios, selects, comboboxes\n - Dropdown menus, popovers, dialogs, drawers, tooltips\n - Tabs, accordions, tables/treegrids, row actions, pagination\n - Keyboard-only interactions and focus traps\n4. List states worth scanning:\n - Default, populated, empty, loading, error/validation visible\n - Disabled/read-only, selected/expanded/open\n - Modal/dropdown/popover open\n - Mobile viewport when layout changes\n\n## What To Check (POUR checklist)\n\n### Perceivable\n- Non-text content has a text alternative; decorative images are hidden from AT.\n- Text contrast ≥ 4.5:1; non-text (icons, borders, focus rings) ≥ 3:1.\n- Layout reflows at 320px / 400% zoom without horizontal scroll or loss of content.\n\n### Operable (keyboard is the big one)\n- Every control is reachable AND operable by keyboard (Enter/Space activate; arrows where expected).\n- Focus is always visible.\n- Focus order is logical and matches visual order.\n- **No keyboard trap — test Shift+Tab too, not just Tab.** Focus can always move out of a widget both ways.\n- Disabled controls are not in the tab order.\n- Composite widgets (grid/tree/listbox/menu/tablist) are ONE logical tab stop with a roving `tabindex`; arrows move within.\n- After async transitions (route change, panel open/close) focus lands somewhere useful, never silently on ``.\n\n### Understandable\n- Inputs have programmatic labels; visible label matches accessible name.\n- Errors are identified in text and associated with their field; give a suggestion when possible.\n- The same control is identified consistently across the app.\n\n### Robust (name / role / value)\n- Interactive elements expose a correct role, name, and state.\n- Valid ARIA parent/child (e.g. `rowgroup` owns `row`, `list` owns `listitem`).\n- No tabbable element with a non-widget role (`presentation`/`none`).\n- `aria-hidden=\"true\"` never wraps a focusable element.\n\n## axe vs IBM: known gaps\n\nThings axe passes but IBM flags (all real WCAG Level 1):\n\n| IBM rule | WCAG | Typical cause |\n| --- | --- | --- |\n| `element_tabbable_role_valid` | 4.1.2 | tabbable element with `role=\"presentation\"` / no widget role (focus sentinels, wrappers) |\n| `aria_child_valid` | 1.3.1 | `rowgroup`/`list`/`tablist` owning no valid child role |\n| `aria_child_tabbable` | 2.1.1 / 4.1.2 | composite widget with no tabbable descendant (needs roving `tabindex`) |\n| `aria_hidden_focus_misuse` | 4.1.2 | focusable element inside `aria-hidden=\"true\"` |\n| `aria_accessiblename_exists` | 4.1.2 | element with a widget role but no accessible name — e.g. an AG Grid `columnheader` with neither `field` nor `headerName` (icon-only action column) |\n| `aria_content_in_landmark` | 1.3.1 | content outside any landmark — e.g. a Radix menu/popover portaled to ``. `role=\"menu\"` is NOT landmark-exempt; only `aria-modal` dialogs are. Often unfixable app-wide → baseline it (see below) |\n\nRule of thumb: touch a table/tree/listbox/menu → scan with IBM.\n\n## Component Gotchas\n\n- **Data grids (AG Grid — the shared `TableComponent`)**: the grid's own tab guards + pagination are the fragile part.\n - Disabled paging buttons must be `tabindex=\"-1\"`, but NEVER `inert`/`disabled` — that breaks AG Grid's tab guards and traps reverse (Shift+Tab) entry (WCAG 2.1.2).\n - AG Grid still *programmatically* focuses disabled paging on tab-out; handle with its `tabToNextCell` hook plus a container-scoped `focusin` redirect (defer the redirect to `requestAnimationFrame` — focus changes inside a `focusin` handler are ignored, and AG Grid restores the last-focused cell on the next tick).\n - Empty rowgroups need `role=\"presentation\"`; the grid needs one roving-tabindex row.\n - **Icon-only / action column header**: AG Grid derives the `columnheader` accessible name from `field`; a column with neither `field` nor `headerName` is nameless (`aria_accessiblename_exists`, 4.1.2). Give it a `headerName` and hide it visually with a `headerClass` (sr-only clip on `.ag-header-cell-text`) so the header stays blank but named.\n - **Interactive control inside a cell** (menu trigger, button): AG Grid navigates **cell-by-cell** and never tab-focuses the inner control, so it's keyboard-inoperable. Activate it from the grid's `onCellKeyDown` on Enter/Space (give the column a `colId` to target it). A **Radix trigger opens on keydown/pointerdown, not a synthetic `.click()`** — focus the trigger and **re-dispatch the key** (`new KeyboardEvent(\"keydown\", {key, bubbles:true})`), guarding against re-entry (skip when `target` is already the button). `TableComponent` spreads `{...props}` to AG Grid, so pass `onCellKeyDown` from the page — no shared-component change.\n - **Focus visible on borderless grids** (`.ag-no-border`): the theme suppresses the cell focus outline (`outline:none`), hiding keyboard focus (2.4.7). Restore it with a `:focus-visible` ring scoped to `.ag-no-border .ag-cell:focus-visible` (+ header/row). `:focus-visible` **distinguishes modality on AG cells** — mouse click resolves to `:focus`, keyboard nav to `:focus-visible` — so the ring shows for keyboard only and mouse stays quiet. CAVEAT when verifying: probe with a **clean, first-interaction** page; a session that already used the keyboard makes `:focus-visible` report `true` for a later mouse click (heuristic contamination).\n - Set `ensureDomOrder: true` so DOM order matches visual order for tab navigation.\n - `TableComponent` is shared across settings/traces — fix once in the grid patch, then re-scan every grid page. Its pagination/tab-out rework lives in LE-1720 / PR #13953; don't duplicate it per-page.\n- **Modals/drawers**: title + description, focus trapped inside while open, focus restored to the trigger on close, Escape closes.\n- **Dropdowns/popovers**: reachable by keyboard, Escape closes, focus returns to the trigger.\n- **Radix (shadcn) primitives** — three recurring traps:\n - **`Trigger asChild` double tab stop**: a `DialogTrigger`/`DropdownMenuTrigger` wrapping a real `