A running sapedbd will create a database it has never seen for any
account and database name whose connection-string signature verifies.
Server.database opens-or-creates the .sapedb file; there is no separate
"this must already exist" gate in front of it.
Verified live, not read: a fresh SAPEDB_DIR, sapedbd started,
apply never run at all, a signed URL minted for an account and database
nobody had used — then Operate and establish. It succeeded, wrote
newacct/newdb.sapedb and its .parts to disk, and returned the collection with
id: 1.
It answers a question that was open: how does anybody seed a remote sapedb? The
earlier reading, written down in this project's own notes, was that
SAPE-14 blocked step one of any seed flow. That reading is now wrong.
Step one works: a database and its collections can be brought into existence over a connection, with no
apply, no file access, and no restart.
What is still missing is narrower and worth stating exactly, because the difference is the whole
remaining gap: sapedb apply takes several files and commits them
all or nothing. Over the wire there is no equivalent — each
establish and each declare commits for itself. So a half-applied schema is
reachable remotely in a way it is not locally, and the caller is the one who has to notice.
Creating a database requires minting a connection string, and minting one requires the
server's secret. So the trust level is the same as apply's: whoever can do
this could already have stopped the daemon and written the file directly. On that reading there is
nothing to fix.
The part that is not obvious, and that nobody had written down anywhere before this page: the namespace is unbounded. One secret does not authorise one database; it authorises every name that passes the character rules. An operator who assumed a connection string reaches an existing database, and only that one, has assumed something the server does not enforce.
Does it lose data, break a promise on a public surface, or stop somebody installing and running? No. Nothing is lost, and nothing published said otherwise — because nothing published said anything about it at all, which is the actual finding.
Defer, with the reservation written where it will be read: this is a property of a surface 1.0.0 freezes. If a later release decides a connection string should only reach a database that already exists, that is a breaking change, not an addition — it would refuse something that works today. The cheap moment to decide is the same moment as ISS-22's, and for the same reason.
What has been done in the meantime is the part that needed no decision: it is now documented, in the agent skill, as behaviour rather than as an accident.