v0.34.1

Bug Fixes

• Fresh installs and existing v0.34.0 deployments fail to start serve because the ORM-based seed (default plugins / library) runs before alembic
  migrations by @arkohut
  • Once LibraryModel gained the kind column in v0.33.0, the seed's SELECT against libraries crashed before run_migrations() had a chance
    to add the column — on PostgreSQL with UndefinedColumn: column libraries.kind does not exist, and on SQLite with the equivalent no such column
    error
  • Split DatabaseInitializer.init_database() into schema-only setup plus a new seed_default_data() step, and reorder the three call sites
    (serve / init / migrate_sqlite_to_pg) to: init_database → run_migrations → seed_default_data
  • Set kind=LibraryKind.RECORD explicitly when seeding the default capture library, so fresh installs (where the migration's name-based UPDATE
    hits an empty table) still end up with the right kind instead of falling through to the static server default

Full Changelog: v0.34.0...v0.34.1

---

Bug 修复

• 修复全新安装以及已安装 v0.34.0 的实例无法启动 serve 的问题：ORM 默认数据 seed（默认插件 / library）在 alembic migration 之前运行 by @arkohut
  • v0.33.0 给 LibraryModel 加上 kind 列后，seed 阶段对 libraries 的 SELECT 在 run_migrations() 还没来得及添加该列时就崩溃 —— PostgreSQL
    上抛 UndefinedColumn: column libraries.kind does not exist，SQLite 上是等价的 no such column 错误
  • 把 DatabaseInitializer.init_database() 拆成仅建表的部分加新的 seed_default_data() 步骤，并把 serve / init / migrate_sqlite_to_pg
    三处调用点统一改为：init_database → run_migrations → seed_default_data
  • 在 seed 默认 capture library 时显式设置 kind=LibraryKind.RECORD，让全新安装（migration 的按名 UPDATE 命中空表）也能拿到正确的 kind，而不是落到
    static 的 server default

完整更新日志: v0.34.0...v0.34.1