Part three continues the engine from parts one and two. The invocation
has not changed:

SQL on stdin, results on stdout, exit 0. Declare (or re-declare) your
commands in AGENTS.md (or README.md): a run: line with the exact
command that starts the engine, e.g. run: sh mydb.sh or
run: python3 db.py, and a test: line with the command that runs
your test suite, e.g. test: sh test.sh. Both are captured into
session memory; every later check invokes exactly what you declared,
with a data directory appended. AGENTS.md wins when both declare one.

The first check replays the ground already earned: CREATE TABLE, two
inserts, then the process is restarted on the same data directory and
must still answer a WHERE and honour an UPDATE — persistence from
part two has to hold before anything new is graded. The output
contract is the one frozen in part one and it does not change here.

Embedding SQLite, DuckDB or any existing SQL engine is not building
one — the parser, the executor and the storage are yours.

Implement ORDER BY <col> on a single INT column, ascending. The rows
go in scrambled; SELECT <col> FROM <table> ORDER BY <col> prints
them smallest first, one value per line, then SELECT <n> — the
contract from part one, only the row order is new.

The check inserts random unique integers in an order that matches
neither ascending nor descending, so only a real sort passes. Worth
20 points.

Two more faces of ORDER BY. With DESC the same INT column prints
largest first. And a TEXT column sorts too: plain bytewise comparison,
the way strcmp would — graded names are lowercase letters and digits
only, so there is no locale to argue with.

Both checks insert in an order that matches neither direction of the
sort. Worth 20 points.

Implement LIMIT <k> and OFFSET <j> on the end of a SELECT ... ORDER BY .... Sort first, skip j rows, print at most k, then
SELECT <n> where n is the number of rows actually printed — the
count reflects the slice, not the table.

The check inserts unique random integers scrambled and asks for a
random slice of the sorted result. Worth 20 points.

Implement SELECT COUNT(*) FROM <table> WHERE <cond>. An aggregate is
still a SELECT: it returns exactly one row — the count, printed as a
plain decimal on its own line — followed by SELECT 1, because one
row came back. A count of zero is the line 0, not SELECT 0.

The check inserts random values on both sides of a random threshold
and asks how many land above it. Worth 20 points.

Implement SUM, MIN and MAX over an INT column, all three in one
select list: SELECT SUM(v), MIN(v), MAX(v) FROM <table>; returns a
single row — the three numbers joined by | in select-list order —
followed by SELECT 1. Plain decimals, no formatting. (No AVG in
this campaign: integer division is a fight for another day.)

Worth 40 points.

Implement GROUP BY with a count per group:
SELECT dept, COUNT(*) FROM <table> GROUP BY dept ORDER BY dept;
prints one dept|count row per distinct value, groups sorted
bytewise ascending, then SELECT <n> where n is the number of
groups.

The check interleaves rows from three random departments so
insertion order proves nothing — only real grouping and counting
passes. Worth 40 points.

Implement CREATE INDEX <name> ON <table> (<col>). A successful
statement prints exactly CREATE INDEX — the first new
acknowledgement since part one. The index is part of the database:
after a restart it still exists, queries on the indexed column still
answer exactly, and creating an index under a name that already
exists prints an ERROR: line — while the process, as always, exits
0 and keeps going.

How you store and use the index is your business; that it survives
and that names collide honestly is graded. Worth 20 points.

The index earns its keep. The check loads one hundred thousand rows
in batched multi-row inserts, builds an index on the id column,
restarts the process, and fires a hundred random point lookups at it.
Every answer must be exact — the frozen contract, at scale.

The whole exchange has to finish inside a generous two-minute bound.
This is a sanity bound, not a stopwatch: the check will not time your
algorithm to the millisecond, but it will notice a database that
grinds. If a lookup walks all hundred thousand rows through a parser
every time, you will feel it. Worth 60 points.