NestJS backend development patterns for the RedisInsight API: module structure, services, controllers, DTOs, dependency injection, and error handling. Use when editing any file under redisinsight/api/**, writing or modifying NestJS modules, controllers, services, DTOs, providers, or when the user mentions the backend, API, or NestJS.
Code-quality standards for RedisInsight: TypeScript strictness, naming conventions (camelCase, PascalCase, UPPER_SNAKE_CASE), linting rules, no `any` without reason, no `!important` in styles, and constant extraction. Use when writing or refactoring any TypeScript/JavaScript code in this repo, when ESLint or Prettier issues come up, or when the user mentions code style, lint, naming conventions, or general code quality.
Playwright end-to-end testing standards for RedisInsight: page object models, test structure, fixtures, navigation patterns, and flaky-test prevention. Use when editing files under tests/e2e-playwright/**, writing Playwright tests, adding page objects, or when the user mentions Playwright, E2E tests, page objects, or end-to-end testing.
React/Redux frontend development patterns for RedisInsight UI: component folder structure, styled-components, hooks, named exports, barrel files, layout components, and theme usage. Use when editing any file under redisinsight/ui/**, writing or modifying React components, Redux slices, styled-components, custom hooks, or when the user mentions UI, frontend, React, Redux, or styled-components.
Critical safety guardrails for protected branches: never commit, push, or force-push directly to main, latest, or release branches; no destructive history rewrites without explicit user approval. Use before any git operation that touches protected branches, before force-push, reset --hard, history rewrite, or branch deletion, or whenever the user asks about merging, pushing, or release branches.
Unit/integration testing standards for RedisInsight using Jest and Testing Library: test structure, the `renderComponent` helper, faker for test data, mocking patterns, and `waitFor` instead of fixed time waits. Use when writing or modifying any `*.spec.ts` or `*.spec.tsx` file, when adding component or slice tests, when debugging flaky tests, or when the user mentions jest, testing library, faker, or test patterns.
Create and name git branches following project conventions. Use when creating branches, checking out new branches, or the user mentions branch naming.
Run, refresh, or recover from RedisInsight's per-project TypeScript error baselines (.tscheck.rec.json). Use when CI reports "baseline is outdated" or "more TS errors than previously recorded", when the user mentions tscheck / type-check / .tscheck.rec.json, when introducing or fixing TS errors, or when reviewing PRs that touch baseline files.