skryba database

Skryba keeps no database file. The catalog, the drafts, the writing-style passages and preferences and the detector score cache are tables of one database: skryba, declared in Stado's database plane and hosted as a Supabase Postgres project.

How a command reaches it

1. stado database resolve skryba --consumer skryba names the credential item, skryba-database.
2. stado service directory connect skarbiec --consumer skryba names this machine's route to Skarbiec.
3. Skarbiec answers pooler_url and ca_certificate of that item to the skryba-database-client bearer in ~/.stado/skryba-database-client-skarbiec-token. That grant covers those two fields and nothing else.
4. Skryba connects to the pooler over TLS, verified against that CA, and runs every statement as an unnamed prepared statement — the pooler runs in transaction mode, where a named statement from one client collides with the next.

The database was created with stado database create skryba --consumer skryba, which reads what one more project adds to the organization's bill before creating it and writes the credential item.

Schemas

Every table lives in the schema skryba. SKRYBA_DATABASE_SCHEMA names another schema of the same database — lowercase letters, digits and underscores, starting with a letter — which is created on first use; unset or blank, it leaves skryba. That is how a journey or a test works on rows of its own in the real database without touching the person's.

Table	Held by
choices, catalog_seeded	skryba style and skryba language
drafts	skryba draft
passages, preferences	skryba writing-style
scores	the detector score cache

skryba database check

Resolves, connects, and prints the schema's tables with their row counts:

{
  "action": "check",
  "database": "skryba",
  "store": "stado://database/skryba/skryba",
  "tables": [ { "table": "choices", "rows": 6 } ]
}

A failure exits 1 and names the step that failed:

• stado database resolve skryba --consumer skryba --json failed … — Stado does not declare the database or refused the consumer.
• stado service directory connect skarbiec --consumer skryba --json failed … — no Skarbiec route for skryba on this machine.
• reading the skryba-database-client bearer <PATH> — the bearer file is missing.
• Skarbiec refused skryba-database-client reading skryba-database#<FIELD>: HTTP <STATUS> … — the grant does not cover the field.
• connecting to the skryba database pooler (stado://database/skryba) with Caused by: the TLS or network error.
• SKRYBA_DATABASE_SCHEMA is set to text that is not Unicode: <BYTES> — the variable holds bytes that are no text. It is refused rather than read as unset, which would put this process's rows in skryba.
• SKRYBA_DATABASE_SCHEMA="<VALUE>" is not a schema name: use lowercase letters, digits and underscores, starting with a letter — the named schema is not one Skryba creates.
• creating schema <SCHEMA> in the skryba database with Caused by: the database's error — the schema could not be created.
• listing the tables of stado://database/skryba/<SCHEMA> with Caused by: the database's error.
• counting <TABLE> in stado://database/skryba/<SCHEMA> with Caused by: the database's error, or counting <TABLE> in stado://database/skryba/<SCHEMA> answered no row — a count that did not come back is a failure, never a table of zero rows.

skryba database drop-schema --schema NAME

Drops the named schema and every table in it, and prints {"action": "drop-schema", "store": …, "dropped": true}. The schema skryba, which holds the person's rows, is refused: the skryba schema holds the person's rows and is never dropped. Journeys in tests/styles/ and Skryba Desktop's catalog journey drop their schema this way when they finish.