Follow test constraints

When adding UI logic or tests, align with the repository’s existing CI/test guardrails—especially global checks and test discovery conventions. - **Respect cross-cutting test rules (e.g., i18n parity):** Don’t introduce changes that require mass updates across all locales/fixtures unless you’re prepared to complete them. If full compliance is out of scope,...

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When adding UI logic or tests, align with the repository’s existing CI/test guardrails—especially global checks and test discovery conventions.

  • Respect cross-cutting test rules (e.g., i18n parity): Don’t introduce changes that require mass updates across all locales/fixtures unless you’re prepared to complete them. If full compliance is out of scope, keep the functional change minimal and defer complete i18n work to a focused follow-up.
  • Follow existing test organization/discovery patterns: Place new tests where Vitest/CI already expects them (e.g., co-located __tests__ for dashboard components if the repo’s vitest.config.ts includes that path). Avoid reorganizing test locations unless you also update imports and discovery configuration.

Example (i18n guardrail pattern):

// Prefer keeping the diff focused when full i18n key rollout is out of scope.
{condition && (
  // Inline callout instead of adding en-only keys that break locale-parity tests.
  <div className="text-xs">...</div>
)}
// Then open a follow-up PR to properly add i18n keys across required locales.

Example (test structure pattern):

// Keep dashboard component tests co-located under the component's __tests__
// so existing Vitest include globs discover them consistently.
// Put your new *.test.tsx next to the component tests rather than in a different folder
// unless the repo-wide convention is being intentionally changed.

Source discussions