1 Commits
Author SHA1 Message Date
zeekayandHanzo Dev 9926a57bcc the same answers are asserted on both engines, and a release cannot land on a build
Base serves its data plane on SQLite and on a server, and only one of them was
ever run. So a corpus builds every fixture through Base's own API, carries no
engine in it, and runs on both: matching without regard to case, truth values,
numbers, numbers reached through a JSON document, paging, sorting, a collection
created down to its columns and declared index, a field added to a live
collection and queried at once, eight concurrent writers, settings that survive
a restart without being stored in the clear, and a backup that refuses where it
cannot hold the database.

A test app is handed a schema carved out of the named server, which is a
millisecond against eighty-five for a database, and the catalog is read through
the current schema, so the isolation is the same. The server is named to the
tests and to nothing else — where a Base lives is still the host's question,
answered in code. Unreachable is a failure rather than a fall back to a file,
because a gate that tests one engine twice reports the health of a gate.

Ordering by text is left out on purpose: bytes on one engine, a collation the
operator chose on the other, so it is not Base's answer to assert.

A release tag is refused at or below what is published, and the free number is
named. A version publishes verbatim and as a bare alias, while a build between
releases derives the next free patch — so the two climb the same series, and a
release below the mark would have republished a build under a name someone had
already pinned. The gate runs before the push, so the collision cannot happen
rather than being reported after it has.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-13 16:00:58 -07:00