Build a SQL engine invoked as:

It reads SQL from stdin, executes statements in order, prints results
to stdout and exits 0. Any language and any entry point works — you
decide. Write an AGENTS.md (or README.md) describing your stack
(language, tooling, layout) and carrying the commands kept in session
memory, starting with a run: line declaring the exact command that
starts the engine, e.g. run: sh mydb.sh, run: python3 db.py, or
run: node db.js. That command is captured into session memory: from
here on every check invokes exactly what you declared with a data
directory appended. AGENTS.md wins when both declare one. Declare a
test: line too — the command that runs your test suite (e.g.
test: sh test.sh).

This part may ignore the data directory argument (tables can live in
memory); part two stores everything in it. Accept it from day one so
the interface never changes.

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

The output contract is frozen for the whole campaign: CREATE TABLE
acknowledges with CREATE TABLE, INSERT with INSERT <n>, a
SELECT prints one |-joined row per line and then SELECT <n>, a
failing statement prints ERROR: <message> and execution continues.

Implement CREATE TABLE <name> (<col> <type>, ...) with two types:
INT and TEXT. A successful statement prints exactly
CREATE TABLE.

Then implement refusal. Creating a table that already exists prints an
ERROR: line instead of a second CREATE TABLE, and selecting from a
table that was never created prints an ERROR: line too. Either way
the process still exits 0 — an error is a result, not a crash.

Implement INSERT INTO <table> VALUES (...) for a single row and
SELECT * FROM <table>.

Each single-row insert prints INSERT 1. SELECT * prints one line
per row — values joined by a single |, columns in declared order, no
header and no padding — followed by SELECT <n>. Rows come back in
insertion order: nothing sorts them yet.

An empty table prints just SELECT 0. Worth 20 points.

Extend INSERT to accept several tuples in one statement:

INSERT INTO t VALUES (1, 'a'), (2, 'b'), (3, 'c');

The acknowledgement carries the count of rows actually inserted —
INSERT 3 for the statement above. The count is not the number of
statements and not always 1: it is what the statement did. All the
rows land, in the order they were written. Worth 20 points.

Implement an explicit select list: SELECT c3, c1 FROM t;.

The output carries only the named columns, in the order the query
names them — not the declared order. SELECT * keeps meaning "every
column, as declared". Selecting a column the table does not have
prints an ERROR: line. Worth 20 points.

Text values round-trip exactly as written. A value with spaces in it
keeps its spaces; a value that looks like a number ('42',
'007') is still text and must print exactly as stored — not
renumbered, not stripped of a leading zero, and never quoted in the
output.

Values are printed bare: the quotes belong to the SQL, not to the
result. Worth 20 points.

A script is a sequence, not a transaction. When one statement fails,
print its ERROR: <message> line and carry straight on with the next
statement; the ones after a bad one still run, and the process still
exits 0.

Syntax that makes no sense at all is an error too — an unparseable
statement gets the same treatment as a semantic one. Worth 20 points.

The whole contract at once. One randomized script across two tables:
creates, single- and multi-row inserts, projections, an empty-table
read, and one planted error — graded as a single exact transcript,
line for line, top to bottom.

Nothing new to implement here if the earlier rungs are honest. What
this rung catches is drift: an extra blank line, a stray header, a
count that is right in isolation and wrong in company. Worth 40
points.