Continue the database you built in parts one and two — same repository,
same two commands:

serve: started as:
sql: started as:

Starting from an empty folder is allowed; your previous work is fetched
for you when the session opens. Either way AGENTS.md (or README.md) has
to carry the three lines the platform captures into session memory:
serve:, sql: and test:. AGENTS.md wins when both files declare
one.

Before this part asks for anything new, it re-checks what the earlier
parts earned: a server that boots and answers, CREATE TABLE and
INSERT that acknowledge, and a WHERE and an ORDER BY answered
correctly over a second connection to the same running server.

Then the work starts: pages on disk, BEGIN / COMMIT / ROLLBACK, a
write-ahead log, and recovery from a CRASH;.

The headline rung of this part: rows outlive the process that wrote
them. One server takes a table and some rows into its data directory
and is then stopped; a brand-new server, started on the same port and
the same data directory, reads them back — same values, same order.

Where and how the rows live inside the directory is your call: one file
per table, a page file, a log, a heap. What is not your call is the
outcome — data written by a server that has since exited is data the
next server serves, and a second lifetime can keep writing to the same
table without losing what the first one put there.

Nothing in memory counts. A process that only saves on exit will pass
this rung and fail the crash rungs later, so it is worth building the
real thing now.

Rows are not the only thing on disk. The catalog — which tables exist,
what columns they declare, in what order — belongs in the data
directory as well, and a server that starts on a directory it did not
create must come up knowing exactly what is in it.

Both directions are checked. A table created by one server can be
inserted into by the next one without being created again; and a table
nobody ever created is still unknown after a restart, so writing to it
answers with an ERROR: line and the session carries on. Recovering
the schema means recovering the absences too.

The data directory is not decoration. After a server has taken writes
and stopped, that directory contains the database: files with your
pages, your catalog, your log. An engine that keeps everything in the
process and rebuilds from somewhere else has not stored anything.

The other half of the same claim is isolation. A server started on a
different, empty data directory is a different database: it shares no
tables, no rows and no memory with the one next door. Nothing may live
beside the binary — no file in the repository root, no cache in the
home directory, no singleton in a temp folder. The directory the server
was handed is the whole world it can see.

Implement BEGIN; and COMMIT;. Each acknowledges with its own
keyword — the line BEGIN, the line COMMIT. Statements between the
two still print their normal acknowledgements, and a transaction
belongs to the connection that opened it: another connection is not in
it.

After the COMMIT the work is permanent in both senses the checks can
reach. A later connection to the same running server sees the rows, and
so does a server started afterwards on the same data directory.
Statements outside a transaction keep autocommitting exactly as they
always have.

Implement ROLLBACK;. It acknowledges with the line ROLLBACK and
undoes everything since the BEGIN — not only inserts: an UPDATE
taken back restores the values the rows had before it.

The undo has to hold in every place the checks can look: the SELECT
right after the ROLLBACK on the same connection, another connection
to the same running server, and a server started later on the same data
directory. A rolled-back row that reappears after a restart is a
rollback that only happened in memory — which means the undo was never
part of what you wrote to disk.

Implement CRASH; — a statement that exists only for the test harness.
It terminates the server process instantly, mid-flight: no flush of
pending work, no tidy save-on-exit, nothing that would not survive the
power cord leaving the wall (abort() is the honest spelling). The
port goes dead with it; the client that sent it may see anything or
nothing.

Then make the contract's promise real: a statement outside a
transaction is durable the moment its acknowledgement line is
printed. The check inserts rows, sees INSERT 1 on the wire, kills
the server with CRASH; from another connection, starts a new server
on the same data directory and expects everything it was promised.

That forces the write-ahead order — append the intent to a log, flush
it to disk, and only then acknowledge. An ack only counts if it reached
the client before the death, so flush the socket as you answer, not at
exit.

The other half of the crash bargain: work inside a transaction that
never reached its COMMIT must vanish when the server dies. The
acknowledgements printed inside an open transaction were provisional —
INSERT 1 after a BEGIN is a receipt, not a promise; only COMMIT
turns receipts into promises.

Here the CRASH; arrives on the very connection that holds the open
transaction, so the server dies with work in flight. Recovery has to
tell the two cases apart: a transaction that was never committed leaves
nothing behind, and a transaction whose COMMIT was acknowledged is
there in full. A log replayer has to know where a transaction started
and whether it ever finished.

Recovery has to be idempotent. After a crash, every server started on
that data directory recovers — and the second one must see exactly what
the first one saw. A replayer that re-applies the log on every start
without remembering what it already applied inserts every surviving row
twice; a recovery that rewrites the log carelessly loses rows on the
second pass.

The check crashes a server holding both autocommitted rows and a
committed transaction, then opens the data directory twice in a row —
two full server lifetimes, one read each. Identical output both times.
Checkpoint after the replay, or make the replay naturally idempotent.

The rungs above proved the storage works. This one asks how it is
built, and a panel of judges reads the repository to answer:
architecture, performance, code craft, tests, and the way the project
is run.

Nothing new to implement. Spend the time you have left where the panel
looks:

• Architecture. Is there a storage layer at all — pages, a buffer,
  a log, a catalog — or is durability sprinkled through the executor?
  Could the on-disk format change without rewriting the SQL, and could
  a new statement be added without touching the log?
• Performance. What does an fsync cost you, how many do you do
  per acknowledgement, and what did you decide to buy with them? Does a
  read touch the disk every time or a buffer you keep? Say what the
  trade-off is instead of hoping nobody asks.
• Code quality. Duplication, dead branches, functions that do four
  things. The measurement probes report duplication; the judge reads
  the rest.
• Tests. Is recovery tested, or only the happy path? A suite that
  never kills a server mid-write has not tested this part — crash
  points, replay, an interrupted transaction, a data directory opened
  twice.
• Technical governance. Write down the on-disk format: what a page
  looks like, what a log record holds, how recovery decides what to
  replay, what the catalog stores. A successor should be able to read a
  file of yours with your document open. Declare your conventions in
  tooling — a formatter, a linter, the test: command that really
  runs.

When you are done, write .ololo/storage-done.md with a short
description of what you built and the decisions you made (at least 10
words).