The finale continues the engine you built in parts one through four —
same folder, same invocation:

SQL on stdin, results on stdout in the contract frozen in part one,
exit 0. Re-declare your commands so this session can find them: an
AGENTS.md (or README.md) with a run: line naming the exact command
that starts the engine (e.g. run: sh mydb.sh, run: python3 db.py)
and a test: line naming 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.

Everything the campaign has earned must still work: tables persist in
the data directory across restarts, WHERE / UPDATE / DELETE,
ORDER BY, and INNER JOIN with qualified names. The check here
builds two tables, restarts the engine, and reads a join back — if
parts one through four stand, this pays from the first probe.

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

Implement BEGIN; and COMMIT;. Each acknowledges with its own
keyword — the line BEGIN, the line COMMIT — per the contract
frozen in part one.

Statements between the two still print their normal acknowledgements
(INSERT 1 and friends), and after the COMMIT the work is permanent:
a SELECT in the same session sees the rows, and so does the next
invocation on the same data directory. Statements outside a
transaction keep autocommitting exactly as they always have.

Worth 20 points.

Implement ROLLBACK;. It acknowledges with the line ROLLBACK and
undoes everything since the BEGIN — not just inserts: an UPDATE
rolled back restores the old values, a DELETE rolled back brings the
rows home.

The undo must hold both ways the checks can look: a SELECT in the
same session right after the ROLLBACK, and a fresh invocation on the
same data directory. A rolled-back row that reappears after a restart
is a rollback that only happened in memory.

Worth 40 points.

Implement CRASH; — a statement that exists only for the test
harness. It terminates the process instantly, mid-flight, with any
nonzero exit code: no flushing of pending state, no tidy save-on-exit,
nothing that would not survive the power cord leaving the wall
(abort() is the honest spelling; exit(0) is cheating twice).

Then make the contract's promise real: a statement outside a
transaction is durable the moment its acknowledgement line is
printed. The check inserts a row, sees INSERT 1, kills the engine
with CRASH;, and expects the row from the next invocation on the
same data directory. That forces the write-ahead order — append the
intent to a log, flush it to disk, and only then acknowledge. And
since an ack only counts if it actually reached stdout before the
death, flush stdout as you print, not at exit.

Worth 60 points.

The other half of the crash bargain: work inside a transaction that
never reached its COMMIT must vanish when the process 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.

The check opens a transaction, inserts, and kills the engine with
CRASH;. The next invocation on the same data directory must see none
of it — and anything autocommitted before the BEGIN must of course
still be there. Recovery that replays the log has to know where a
transaction started and that it never finished.

Worth 40 points.

A transaction is atomic across a crash. Two checks, one boundary:

A transaction that inserts one row and updates another, killed
before its COMMIT, applies nothing — the insert is gone and the
update never touched the old value. The same transaction killed right
after the COMMIT acknowledgement applies everything — the new row
is there and the update stuck.

The line is the COMMIT ack: the moment COMMIT is on stdout, the
whole transaction is durable as a unit; one byte earlier, none of it
ever happened. In log terms — a commit record, flushed, before the
ack; recovery replays transactions that have one and skips
transactions that do not. Half-applied transactions are the one
unforgivable outcome.

Worth 60 points.

Recovery must be idempotent. After a crash, every invocation 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 open
without remembering what was already applied inserts every surviving
row twice; a recovery that rewrites the log carelessly can lose rows
on the second pass.

The check crashes an engine that holds both autocommitted rows and a
committed transaction, then opens the data directory twice in a row
and reads the table both times. Identical output, both times —
checkpoint after replay, or make the replay naturally idempotent.

Worth 20 points.

Everything this part earned, interleaved and killed. One randomized
script: rows autocommitted between transactions, a transaction that
commits, a transaction that rolls back, another autocommit, and a
transaction still open when CRASH; pulls the plug — inserts and
updates woven through all of them.

The final invocation reads the table back with ORDER BY id, and the
surviving set is computed independently: every autocommitted statement
and every committed transaction survives, the rolled-back and the
in-flight transactions leave no trace — not even their updates to rows
that themselves survive. Every acknowledgement before the kill is
checked too, so the engine has to be honest twice: once while alive,
once from the grave.

Worth 60 points.