[WaylandYang]

Closes #322.

insert_general_kb created the General base during registration and installed nothing, while creating a base through the UI installs whatever was ticked — schema.org by default. So the first base of every deployment, the one a new user lands in and uploads their first document to, started with zero classes and zero properties.

Both records had already decided this. 0008's status line: schema.org checked by default. 0009 decision 1: "schema.org is pre-checked in the create dialog". An empty ontology is a path 0009 supports — build the base first, model later — but it is a path someone chooses, and this base skipped the dialog where the choice is offered. What 0008 argues is what was lost: without domain and range the extraction prompt falls back to prose, direction cannot be pinned, and facts degrade to related_to.

The awkward part

insert_general_kb runs inside the registration transaction in the store layer. install_packs needs AppState — it reads the embedded pack and goes through OWL import — so it cannot join that transaction. Registration now returns Registered { user, workspace, general_kb }, and the handler installs the pack after the commit. general_kb is Some only on the bootstrap path, so a second registration joining an existing workspace installs nothing.

A failed install does not fail the registration. The transaction is already committed and the account exists; failing here would turn "the base has no vocabulary" into "you cannot sign up", and the former is recoverable — install a pack later and rerun type resolution (0009). It logs a warning instead.

One pack, not five: DEFAULT_PACK is the same default the create dialog offers, so both paths now agree by construction rather than by coincidence.

Verified

On a fresh database: register the first user, and the default base comes up with 915 classes and 1625 properties — person, organization, product, event all present. Registering a second user leaves it at 915, confirming the bootstrap-only path.

Existing deployments need no backfill: migrations only roll forward here, and per 0009 an older base can install a pack and rerun type resolution to pick up types for entities already extracted.

cargo fmt --check, cargo clippy -D warnings, cargo test --workspace with UTOPIA_TEST_REQUIRE_DB=1 all pass.

Checked while here

Whether the default pack would bring in unreadable keys — it does not. Measured across both packs: schema.org produces 0 opaque keys out of 915 classes and 1625 properties (its digit-bearing keys all carry meaning: gtin12, emissions_co2, has_gs1_digital_link). The bfo_0000144 kind comes from IOF Core referencing BFO, and is filed separately as #324.

🤖 Generated with Claude Code