📄 CodeRabbit inference engine (.cursor/rules/gh-cli-workflow.mdc)

Prefer not to introduce new TypeScript types; use existing interfaces whenever possible

**/*.{ts,tsx}: Follow consistent import order (Biome will handle sorting)
Use curly braces for all control statements
Prefer const over let; avoid var
Use object property shorthand when possible
Use async/await for asynchronous code
Use consistent error handling with proper type checks

Files:

• src/redteam/constants/plugins.ts
• src/redteam/constants/metadata.ts
• src/redteam/plugins/openaiGuardrails.ts
• site/docs/_shared/data/plugins.ts
• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx
• src/redteam/plugins/index.ts
• test/redteam/plugins/openaiGuardrails.test.ts

📄 CodeRabbit inference engine (src/redteam/CLAUDE.md)

src/redteam/**/*.ts: Always sanitize when logging test prompts or model outputs by passing them via the structured metadata parameter (second argument) to the logger, not raw string interpolation
Use the standardized risk severity levels: critical, high, medium, low when reporting results

Files:

• src/redteam/constants/plugins.ts
• src/redteam/constants/metadata.ts
• src/redteam/plugins/openaiGuardrails.ts
• src/redteam/plugins/index.ts

📄 CodeRabbit inference engine (CLAUDE.md)

src/**/*.{ts,tsx}: Sanitize sensitive data before logging; pass context objects to logger methods (debug, info, warn, error) for automatic redaction
Do not interpolate secrets into log messages (avoid stringifying headers/bodies directly); use structured logger context instead
Use sanitizeObject for manual sanitization before using or persisting potentially sensitive data

Files:

• src/redteam/constants/plugins.ts
• src/redteam/constants/metadata.ts
• src/redteam/plugins/openaiGuardrails.ts
• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx
• src/redteam/plugins/index.ts

📄 CodeRabbit inference engine (src/redteam/CLAUDE.md)

src/redteam/plugins/**/*.ts: Place vulnerability-specific test generators as plugins under src/redteam/plugins/ (e.g., pii.ts, harmful.ts, sql-injection.ts)
New plugins must implement the RedteamPluginObject interface

Files:

• src/redteam/plugins/openaiGuardrails.ts
• src/redteam/plugins/index.ts

📄 CodeRabbit inference engine (.cursor/rules/gh-cli-workflow.mdc)

Any pull request that only touches files in 'site/' or 'examples/' directories must use the 'docs:' prefix in the PR title, not 'feat:' or 'fix:'

Files:

• site/docs/_shared/data/plugins.ts
• site/docs/red-team/plugins/openai-guardrails.md

📄 CodeRabbit inference engine (.cursor/rules/gh-cli-workflow.mdc)

If the change is a feature, update the relevant documentation under 'site/'

Files:

• site/docs/_shared/data/plugins.ts
• site/docs/red-team/plugins/openai-guardrails.md

📄 CodeRabbit inference engine (src/app/CLAUDE.md)

src/app/src/**/*.{ts,tsx}: Never use fetch() directly; always use callApi() from @app/utils/api for all HTTP requests
Access Zustand state outside React components via store.getState(); do not call hooks outside components
Use the @app/* path alias for internal imports as configured in Vite

Files:

• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx

📄 CodeRabbit inference engine (src/app/CLAUDE.md)

src/app/src/{components,pages}/**/*.tsx: Use the class-based ErrorBoundary component (@app/components/ErrorBoundary) to wrap error-prone UI
Access theme via useTheme() from @mui/material/styles instead of hardcoding theme values
Use useMemo/useCallback only when profiling indicates benefit; avoid unnecessary memoization
Implement explicit loading and error states for components performing async operations
Prefer MUI composition and the sx prop for styling over ad-hoc inline styles

Files:

• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx

📄 CodeRabbit inference engine (.cursor/rules/react-components.mdc)

**/*.{tsx,jsx}: Use icons from @mui/icons-material
Prefer commonly used icons from @mui/icons-material for intuitive experience

Files:

• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx

📄 CodeRabbit inference engine (CLAUDE.md)

In the React app (src/app), use callApi from @app/utils/api for all API calls; do not use fetch directly

Files:

• src/app/src/pages/redteam/setup/components/PluginConfigDialog.tsx

📄 CodeRabbit inference engine (.cursor/rules/docusaurus.mdc)

site/docs/**/*.md: Prioritize minimal edits when updating existing documentation; avoid creating entirely new sections or rewriting substantial portions; focus edits on improving grammar, spelling, clarity, fixing typos, and structural improvements where needed; do not modify existing headings (h1, h2, h3, etc.) as they are often linked externally.
Structure content to reveal information progressively: begin with essential actions and information, then provide deeper context as necessary; organize information from most important to least important.
Use action-oriented language: clearly outline actionable steps users should take, use concise and direct language, prefer active voice over passive voice, and use imperative mood for instructions.
Use 'eval' instead of 'evaluation' in all documentation; when referring to command line usage, use 'npx promptfoo eval' rather than 'npx promptfoo evaluation'; maintain consistency with this terminology across all examples, code blocks, and explanations.
The project name can be written as either 'Promptfoo' (capitalized) or 'promptfoo' (lowercase) depending on context: use 'Promptfoo' at the beginning of sentences or in headings, and 'promptfoo' in code examples, terminal commands, or when referring to the package name; be consistent with the chosen capitalization within each document or section.
Each markdown documentation file must include required front matter fields: 'title' (the page title shown in search results and browser tabs) and 'description' (a concise summary of the page content, ideally 150-160 characters).
Only add a title attribute to code blocks that represent complete, runnable files; do not add titles to code fragments, partial examples, or snippets that aren't meant to be used as standalone files; this applies to all code blocks regardless of language.
Use special comment directives to highlight specific lines in code blocks: 'highlight-next-line' highlights the line immediately after the comment, 'highligh...

Files:

• site/docs/red-team/plugins/openai-guardrails.md

📄 CodeRabbit inference engine (site/docs/CLAUDE.md)

site/docs/**/*.{md,mdx}: Use the term "eval" not "evaluation" in documentation and examples
Capitalization: use "Promptfoo" (capitalized) in prose/headings and "promptfoo" (lowercase) in code, commands, and package names
Every doc must include required front matter: title and description
Only add title= to code blocks when showing complete runnable files
Admonitions must have empty lines around their content (Prettier requirement)
Do not modify headings; they may be externally linked
Use progressive disclosure: put essential information first
Use action-oriented, imperative mood in instructions (e.g., "Install the package")

Files:

• site/docs/red-team/plugins/openai-guardrails.md

📄 CodeRabbit inference engine (.cursor/rules/gh-cli-workflow.mdc)

Avoid disabling or skipping tests unless absolutely necessary and documented

Files:

• test/redteam/plugins/openaiGuardrails.test.ts

📄 CodeRabbit inference engine (.cursor/rules/jest.mdc)

test/**/*.{test,spec}.ts: Mock as few functions as possible to keep tests realistic
Never increase the function timeout - fix the test instead
Organize tests in descriptive describe and it blocks
Prefer assertions on entire objects rather than individual keys when writing expectations
Clean up after tests to prevent side effects (e.g., use afterEach(() => { jest.resetAllMocks(); }))
Run tests with --randomize flag to ensure your mocks setup and teardown don't affect other tests
Use Jest's mocking utilities rather than complex custom mocks
Prefer shallow mocking over deep mocking
Mock external dependencies but not the code being tested
Reset mocks between tests to prevent test pollution
For database tests, use in-memory instances or proper test fixtures
Test both success and error cases for each provider
Mock API responses to avoid external dependencies in tests
Validate that provider options are properly passed to the underlying service
Test error handling and edge cases (rate limits, timeouts, etc.)
Ensure provider caching behaves as expected
Always include both --coverage and --randomize flags when running tests
Run tests in a single pass (no watch mode for CI)
Ensure all tests are independent and can run in any order
Clean up any test data or mocks after each test

Files:

• test/redteam/plugins/openaiGuardrails.test.ts

📄 CodeRabbit inference engine (test/CLAUDE.md)

test/**/*.test.ts: Never increase Jest test timeouts; fix slow tests instead (avoid jest.setTimeout or large timeouts in tests)
Do not use .only() or .skip() in committed tests
Add afterEach(() => { jest.resetAllMocks(); }) to ensure mock cleanup
Prefer asserting entire objects (toEqual on whole result) rather than individual fields
Mock minimally: only external dependencies (APIs, databases), not code under test
Use Jest (not Vitest) APIs in this suite; avoid importing vitest
Import from @jest/globals in tests

Files:

• test/redteam/plugins/openaiGuardrails.test.ts

📄 CodeRabbit inference engine (test/CLAUDE.md)

Organize tests to mirror src/ structure (e.g., test/providers → src/providers, test/redteam → src/redteam)

Files:

• test/redteam/plugins/openaiGuardrails.test.ts

📄 CodeRabbit inference engine (CLAUDE.md)

test/**/*.{test.ts,test.tsx,spec.ts,spec.tsx}: Follow Jest best practices using describe/it blocks in tests
Write tests covering both success and error cases for all functionality

Files:

• test/redteam/plugins/openaiGuardrails.test.ts

Learnt from: CR
PR: promptfoo/promptfoo#0
File: src/redteam/CLAUDE.md:0-0
Timestamp: 2025-10-05T16:59:20.507Z
Learning: Applies to src/redteam/test/redteam/**/*.ts : Add tests for new plugins under test/redteam/

Applied to files:

• test/redteam/plugins/openaiGuardrails.test.ts

src/types/index.ts (2)

• TestCase (702-702)
• Assertion (555-555)

src/util/fetch/index.ts (1)

• fetchWithTimeout (133-159)

src/providers/shared.ts (1)

• REQUEST_TIMEOUT_MS (9-9)

src/redteam/plugins/openaiGuardrails.ts (1)

• OpenAIGuardrailsPlugin (165-246)

src/redteam/plugins/openaiGuardrails.ts (2)

• OpenAIGuardrailsPlugin (165-246)
• fetchDataset (55-163)

src/util/fetch/index.ts (1)

• fetchWithTimeout (133-159)

[failure] 224-224:
Property 'includeSafe' does not exist on type 'PluginConfig'.

[failure] 286-286:
Object literal may only specify known properties, and 'includeSafe' does not exist in type 'PluginConfig'.

[failure] 260-260:
Object literal may only specify known properties, and 'includeSafe' does not exist in type 'PluginConfig'.

[failure] 228-228:
Object literal may only specify known properties, and 'includeSafe' does not exist in type 'PluginConfig'.