Before you make a merge request: Checklist for common mistakes

Merge requests are often rejected for similar reasons. To avoid this, go through the following checklist before making a merge request.

Human checks

• The change fulfills all acceptance criteria.
• You have manually reviewed and understood the entire diff. Don't ask reviewers to check decisions you haven't made yourself.
• The agent has not needlessly duplicated existing logic or concepts.
• The solution is reasonably simple and fits the existing architecture.
• You have manually tested the change in an actual browser.
• The UI/UX looks and feels good.

Agent checks

• The diff contains no unrelated changes, accidental edits, or debugging statements (console.log, debugger, etc.).
• All tests are passing.
• New or changed behavior is covered by tests. Prefer few E2E tests for critical user flows and many fast unit tests for details and edge cases.
• There are no missing translations in the UI
• The change performs with large datasets: no N+1 queries, excessive query counts, or unnecessarily large in-memory collections.
• All lists are sorted (indexes, select dropdowns, ...).
• Long index lists are paginated.
• Database queries and foreign key lookups have indexes.
• Migrations correctly handle existing records and leave no invalid data behind.
• New tables have created_at and updated_at timestamps (t.timestamps)
• Relevant documentation (README.md, AGENTS.md, Cards) is updated where necessary.
• If any UI was added or changed, a screenshot or video was attached to the MR.