knowledge-schemalisted

# ナレッジschemaを変更する ## Triggers - `db/schema.sql`のtable、列、CHECK、index、view、triggerを変更する - `db/migrations`へ手順を足す、または`gleanery db migrate`を既存のDBへ当てる - 接続の役割（`server/src/sqlite.ts`・`server/src/db-write.ts`のauthorizer）を変える - 全文検索の索引（FTS5、`gleanery_terms`、`server/src/text.ts`の`terms()`）を変える - `knowledge`の種類・状態・stance、`message`の話者、`conversation`の出自、`message_file`の操作を変更する - 取り込み元を足す、またはGitHub同期・文書同期・自動記録・traceの書き方を変える ## Does not trigger - 既存schemaを読むだけの端末の画面を変更する - DBを作るだけの作業を行う ## 正本とバージョン DBは`node:sqlite`の1ファイル（`~/.gleanery/gleanery.db`）。正本は`db/schema.sql`の1本で、今の形だけを表す。 Prisma・Drizzleのschemaを別の正本として足さない（Drizzleは不採用。FTS5の仮想表とtriggerを表せない）。 新しいDBは`gleanery init`が一時ファイルへschema.sqlを当ててからrenameして作る（何度流してもよい）。 バージョンは`pragma user_version`で持つ。schema.sqlの末尾の`pragma user_version = N`と`server/src/sqlite.ts`の `SCHEMA_REVISION`を同じ数にする。readerとingestの接続は開くときに照合し、食い違えば止まる。 **自動記録（capture）だけは照合しない。**確かめると、DBを上げてからpluginを上げるまで記録が丸ごと止まる。 旧バージョンのまま書き続け、DBが弾いた記録は`rejected/`へ回る。 `db/migrations/NNNN_<名前>.sql`は既存のDBをrevision N-1からNへ進める手順で、正本ではない。 `gleanery db migrate`（`server/src/admin.ts`の`applyMigrations`、owner）は、DBのバージョンより新しいmigrationを番号順に当て、 **transactionごとに**`user_version`を上げる。途中で落ちても前のtransactionの分は残り、打ち直すとその続きから当たる。 - 宣言の無いmigrationは、続く分をまとめて1つのtransaction（`begin immediate`）で当てる - 表を消す・作り変える（`ALTER TABLE`。列の追加も含む）migrationは、1行目に`-- gleanery: foreign_keys=off`を書く。宣言の無いmigrationでは、runnerのauthorizerがdropとALTERを拒む。単独のtransactionで、その外で外部キーを切って当て、 commitの前に`pragma foreign_key_check`が空であることを確かめ