Part two continues the engine you built in part one, in the same repo:
the invocation, the SQL dialect and the output contract are unchanged,
and this session's checks pick up where part one's left off. If the
folder is empty, fetch or recreate your part-one work first — the
engine must already speak SQL before any new points arrive.

Re-declare the commands kept in session memory. AGENTS.md (or
README.md) carries a run: line with the exact command that starts
the engine, e.g. run: sh mydb.sh, run: python3 db.py, or
run: node db.js, and a test: line with the command that runs your
test suite, e.g. test: sh test.sh. AGENTS.md wins when both declare
one. From here on every check invokes exactly what you declared with
a data directory appended.

One check replays part one's contract in a single script — CREATE TABLE, INSERT, a planted error that must not stop the run, and a
SELECT that reads the row back. After this task the data directory
argument stops being decoration: everything that follows stores into
it.

The headline feature of this part: persistence. One invocation of the
engine creates a table and inserts rows into its data directory; a
second invocation — a brand-new process pointed at the same directory
— selects them back, byte for byte, in insertion order.

Where and how the data lives inside the directory is your call: one
file per table, a page file, JSON, a log. What is not your call is
the outcome — rows written by a process that has since exited are
readable by the next one, and reading them does not consume them: a
third invocation sees exactly what the second one saw. Worth 40
points.

Persistence covers the catalog, not just the rows. One invocation only
creates a table and exits; the next invocation inserts into it without
re-creating it and reads the row back — column names, order and types
all come from the schema stored in the data directory.

Unknown tables stay unknown: inserting into a table that no invocation
ever created prints an ERROR: line, and the process still exits 0.
Worth 20 points.

Implement WHERE with equality: SELECT ... FROM <table> WHERE <col> = <value> filters rows before they print, comparing an INT column
against a number and a TEXT column against a quoted string.

Only the matching rows print, in insertion order, followed by
SELECT <n> counting the matches. A condition nothing satisfies is
not an error — it is SELECT 0. Worth 20 points.

Extend WHERE with the comparison operators on INT columns: <,
>, <=, >= and <>. Numbers compare as numbers — 900 is less
than 1000 — and the same random threshold is probed from every side
in one script, with one row sitting exactly on it, so the strict and
inclusive variants must genuinely differ.

The output shape is unchanged: matching rows in insertion order, then
SELECT <n>. Worth 40 points.

Combine two predicates: WHERE <p> AND <q> keeps the rows both
predicates accept, WHERE <p> OR <q> keeps the rows either accepts.
A predicate on either side is any comparison from the previous tasks,
on an INT or a TEXT column — the checks mix them.

The output shape is unchanged: matching rows in insertion order, then
SELECT <n>. Worth 20 points.

Implement UPDATE <table> SET <col> = <value> WHERE <cond>. The
acknowledgement is UPDATE <n> where <n> is exactly the number of
rows the condition matched — updating nothing prints UPDATE 0, and
that is a result, not an error.

The change is durable: a later invocation against the same data
directory sees the new values, with untouched rows exactly as they
were and insertion order preserved. Worth 40 points.

Implement DELETE FROM <table> WHERE <cond>. The acknowledgement is
DELETE <n> with the honest count of removed rows — deleting nothing
prints DELETE 0, and that is a result, not an error.

Deletion is durable: a later invocation against the same data
directory sees only the survivors, in their original insertion order,
and the closing SELECT <n> counts the shrunken table. Worth 40
points.

The data directory is the whole database. Run the engine against a
brand-new empty directory and it must know nothing: selecting the
table you created elsewhere prints an ERROR: line — not SELECT 0
and not the other directory's rows — and the process still exits 0.

Two directories are two independent worlds: the same table name may
exist in both with different contents and neither leaks into the
other. No global state lives outside the directory the engine was
pointed at. Worth 10 points.