Write a pull request description

Create a PR description that helps reviewers understand the change, how to test it and what to watch for.

Change note: Initial version

Prompt

Write a pull request description for reviewers.

Change summary or diff:
{{changes}}

Problem being solved (and link): {{problem}}
Type of change: {{type}}
How I tested it: {{testing}}
Known limitations or follow-ups: {{followups}}

Use this structure, in Markdown:
## Summary
Two or three sentences: what changed and why, written for someone with no prior context.
## Changes
A short bullet list grouped by area. Mention anything surprising.
## How to review
Where to start, which files carry the real logic, and which are mechanical (renames, generated code).
## Testing
What was run, plus step-by-step manual verification a reviewer can repeat.
## Risks and rollout
Impact on existing behavior, migrations, config or feature flags needed, and how to roll back.
## Screenshots or output
Leave a placeholder only if the change is visible.

Keep it concise and skimmable. Do not invent test results: if my testing notes are thin, list what is still unverified under Testing. Do not repeat the diff line by line.

Variables

• {{changes}}Changes or difflongrequired

  Paste the diff, a commit list or your notes.

• {{problem}}Problem and linktext

  Default: Search results are slow for large accounts (#1204)

• {{type}}Type of changeselect

  Options: Bug fix, Feature, Refactor, Performance, Dependency update, Documentation

  Default: Performance

• {{testing}}How you testedlong

  Default: Unit tests added; ran locally against a copy of a large account

• {{followups}}Limitations and follow-upstext

  Default: Cache invalidation on bulk import is still manual

Example output

## Summary
Search on large accounts took 3-8 seconds because every query loaded all documents before filtering. This PR moves filtering into the database query and adds an index, bringing the typical query under 200 ms. Fixes #1204.

## Changes
- `search/query.ts`: filters and pagination now happen in SQL
- `migrations/0042_search_index.sql`: adds a composite index on `(account_id, updated_at)`
- `search/query.test.ts`: tests for filters, empty results and pagination

## How to review
Start with `search/query.ts`; the migration is one statement; the test file is the quickest way to see the new behavior.

## Testing
- Unit tests pass.
- Manual: open an account with more than 50k documents and search "invoice"; results should appear in under half a second.
- Not yet verified: behavior under concurrent imports.

## Risks and rollout
The migration builds an index on a large table; run it during low traffic. Roll back by reverting the PR and dropping the index. Follow-up: cache invalidation after bulk import is still manual.

Notes

Giving the model a fixed structure and a how-to-review section saves reviewers time. The rule against inventing test results keeps the description honest.