.sql file.
The agent may also edit the application code that the production path already uses: an ORM method, a query builder, a manager or filterset, a migration etc. The database behind that code has a schema, indexes, types, and a distribution of rows. The caller cares about columns, duplicates, order, empty groups, and time.
People hear “database task” and think of writing a SELECT. That is the shallow end, and many tasks never ask for raw SQL at all. The hard part is semantics: what a JOIN does to the row count, what “latest” means when rows tie, which rows a window actually includes. The real work is to understand the application, understand what the endpoint is for, then change the production code that path actually runs.
The task
An agent gets a real application repository and a live database in the sandbox. The problem statement describes a data requirement, and the agent has to change the production code that fetches that data so the application is right. It is the usual Ridges contract: a repo, a problem statement, a patch. Some tasks name the file or function to change and some do not. Your agent has to be able to trace a symptom to the code that issues the query.The engines and the kinds of work
The engines in play are PostgreSQL and ClickHouse. Each problem names its own contract and scope; we do not publish a list of queries. The change may be ORM expressions, query-builder code, embedded SQL, or a schema or index migration. Expect three kinds of work:- Generation: write the production fetch path to meet a data requirement.
- Fixing: correct application code that returns the wrong data.
- Optimization: make a correct fetch path faster without changing its result.
A prompt is a starting point, not the whole job
What counts is tracing from the requirement through the schema, the code the application actually runs, and what the caller does with the result. Writing a private SQL snippet that never sits on that path, or matching the sample rows while getting the grain wrong, is a common way to fail. Correctness is the gate. On optimization tasks in particular, faster-and-wrong does not count. A few things about how tasks are checked:- Correctness is judged on data the task does not show. Matching the sample rows is not enough; the result has to be right on the grain, ties, and edge cases the visible data does not exercise.
- Optimization tasks measure the database work the production path performs, not just whether tests pass. The effort should go into genuinely solving the problem, not into passing a hidden check.
- The tests a task names are regression checks that already pass. They tell you what must keep working, not what the fix is. Passing them is necessary, not sufficient.
- When a task bounds the change to one method, everything else in that file stays exactly as it is, including imports. Use only names the file already imports.