latticesql 1.16.2 → 1.16.4

package/README.md

@@ -2095,13 +2095,24 @@ a parent link, while the reverse side (other entities that point here) plus
 many-to-many junctions become the drill-in sub-folders. Declare `ref:` on your
 foreign-key fields to get the nested file tree.
 
-The header carries the logo, undo/redo, the workspace (database) switcher, and a
-**settings gear** (top-right). The gear opens a slide-over drawer with **Database**,
+The header carries the logo, undo/redo, the **workspace switcher**, and a
+**settings gear** (top-right). The gear opens a slide-over drawer with **Workspace**,
 **Lattice**, and **User** settings plus an **Advanced mode** toggle. Turn Advanced
 mode on to switch the object/row views back to the classic editable **table + row**
 interface (below); turn it off for the file-system workspace. The left sidebar is
 slim and collapsible. The assistant rail is unchanged in either mode.
 
+**One workspace model (v1.16.4+).** A workspace _is_ a Lattice DB. The header has a
+single workspace switcher listing every database — local or cloud, created or joined —
+and its "+ New workspace…" button opens the create/join wizard (New local / New cloud /
+Join existing cloud). The GUI always operates inside a `.lattice` root: opening a bare
+config adopts it (and its database, referenced in place — nothing is moved) as the
+active workspace. There is no separate "database mode". The word "database" is reserved
+for a specific workspace's connection details (the connection panel in Workspace
+Settings). This applies to the GUI/CLI app only — the `latticesql` library API and the
+headless `render`/`generate`/`watch` commands still run against a bare config or
+Postgres URL with no root.
+
 ### Assistant sidebar (v2.0+)
 
 The GUI has a fixed right sidebar with a live **activity feed** — every change
@@ -2142,11 +2153,11 @@ Chat threads, files, and secrets are all stored as native Lattice entities.
 
 The convergence means you don't need to duplicate entity-context definitions in YAML for the GUI to find rendered files.
 
-**Database wizard form (v1.13.2+).** The Postgres connection form (used by Migrate to cloud + Connect to existing cloud) disables browser autocapitalize, autocorrect, and spellcheck on every text input, and trims whitespace on every read. This avoids silent failure modes where macOS Safari / iOS turned a Supabase tenant user `postgres.<ref>` into `Postgres.<ref>` on submit, and where pasted credentials carrying a trailing newline produced opaque "zero-length delimiter identifier" or SCRAM-mismatch errors. `probeCloud` also folds SQLSTATE + `routine` into `result.error` so the GUI's "Unreachable: …" surface is actionable.
+**Database wizard form (v1.13.2+).** The Postgres connection form (used by Migrate to cloud + the Join-a-team invite flow) disables browser autocapitalize, autocorrect, and spellcheck on every text input, and trims whitespace on every read. This avoids silent failure modes where macOS Safari / iOS turned a Supabase tenant user `postgres.<ref>` into `Postgres.<ref>` on submit, and where pasted credentials carrying a trailing newline produced opaque "zero-length delimiter identifier" or SCRAM-mismatch errors. `probeCloud` also folds SQLSTATE + `routine` into `result.error` so the GUI's "Unreachable: …" surface is actionable.
 
-**Switch vs. migrate (v1.13.2+ wording).** "Connect to existing cloud" _switches_ the project's `db:` line to point at the cloud; the local SQLite file stays on disk and you can switch back by editing the YAML or via the Databases catalog under User Config. Use "Migrate to cloud" only when you want to _push_ the local data into a fresh empty target.
+**Migrate vs. join (1.16.4).** The standalone "Connect to existing cloud" wizard (which switched a project's `db:` line to a raw cloud on its own) was removed — the two cloud operations are now **Migrate to cloud** (push your local workspace's data into a fresh cloud Postgres; you become the owner) and **Join a team (invite)** (redeem an invite token to join a workspace someone shared with you). The `connect-existing` endpoint still backs the invite‑redeem path for an active cloud that needs an invite.
 
-**Upgrade to team cloud — works against direct Postgres URLs (v1.13.3+).** The "Upgrade to team cloud" action previously HTTP-POSTed to `/api/auth/register` on the cloud URL, which fails with `Request cannot be constructed from a URL that includes credentials` when the cloud URL is a Postgres connection string. v1.13.3 dispatches on URL scheme: `http(s)://` keeps the HTTP path; `postgres(ql)://` calls the new `registerDirectViaPostgres()` helper that drives the same INSERT sequence directly against the cloud Postgres. Same invariants enforced both ways.
+**Cloud workspaces initialize automatically (v1.16.3+).** A cloud database _is_ a cloud workspace with members — there is no separate "upgrade to team" step. The moment a database is migrated or connected to Postgres, its member/share machinery is created automatically (the workspace name is used as the identity; an existing un-initialized cloud initializes on open, with the opener as owner). The underlying mechanism is the `registerDirectViaPostgres()` helper, which drives the identity/member INSERT sequence directly against the cloud Postgres (the older HTTP `/api/auth/register` path is still used when the cloud URL is `http(s)://`). The standalone "Upgrade to team cloud" action and its `/api/dbconfig/upgrade-to-team` route were removed in 1.16.3.
 
 **Dashboard renders every entity (v1.13.3+).** Previously the dashboard cards filtered through a hardcoded entity list (`meetings`, `people`, `messages`, `projects`, `repositories`, `files`). Installs whose YAML declared different names saw a blank dashboard. Now every first-class entity gets a card; the hardcoded list survives as an ordering preference only.
 
@@ -2160,7 +2171,7 @@ The convergence means you don't need to duplicate entity-context definitions in
 - **Table view** (`#/objects/<entity>`, Advanced mode) — intrinsic columns, `belongsTo` chips, and a column per junction this entity participates in.
 - **Detail view** (`#/objects/<entity>/<id>`, Advanced mode) — read mode by default; `Edit` flips cells into inputs (`Save` PATCHes, `Cancel` reverts).
 - **Settings** (v2.0+) — opened from the header gear (Database / Lattice / User tabs + the Advanced-mode toggle); the legacy `#/settings/*` hashes still resolve and open the drawer.
-- **Data Model** (inside **Database Settings**, v1.14+) — entity-level graph including the native `files`/`secrets` objects, with a per-entity editor. On a team cloud each table you own carries a **Share with team / Unshare** toggle. (Pre-1.14 this was a separate `#/settings/data-model` nav item; that hash still resolves for back-compat.)
+- **Data Model** (inside **Workspace Settings**, v1.14+) — entity-level graph including the native `files`/`secrets` objects, with a per-entity editor. On a cloud workspace each table you own carries a **Share with workspace / Make private** toggle, and graph nodes are colored by share status (yellow = shared, red = private, green = selected) with a legend. (Pre-1.14 this was a separate `#/settings/data-model` nav item; that hash still resolves for back-compat.)
 
 **Internal tables added on first open**
 
@@ -2176,22 +2187,22 @@ These tables are prefixed with `_lattice_gui_` and are hidden from `/api/entitie
 
 **HTTP surface** (all routes scoped to `http://127.0.0.1:<port>/api`):
 
-| Route                          | Method | Lattice call                                                    |
-| ------------------------------ | ------ | --------------------------------------------------------------- |
-| `/project`                     | GET    | (config + manifest summary)                                     |
-| `/entities`                    | GET    | tables + `db.count` per table                                   |
-| `/graph`                       | GET    | (schema graph for Data Model)                                   |
-| `/tables/:table/rows`          | GET    | `db.query(table, …)`                                            |
-| `/tables/:table/rows`          | POST   | `db.insert(table, body)`                                        |
-| `/tables/:table/rows/:id`      | GET    | `db.get(table, id)`                                             |
-| `/tables/:table/rows/:id`      | PATCH  | `db.update(table, id, body)`                                    |
-| `/tables/:table/rows/:id`      | DELETE | `db.delete(table, id)`                                          |
-| `/tables/:junction/link`       | POST   | `db.link(junction, body)`                                       |
-| `/tables/:junction/unlink`     | POST   | `db.unlink(junction, body)`                                     |
-| `/schema/entities`             | POST   | create a new entity/table                                       |
-| `/schema/entities/:name/share` | POST   | share/unshare a table you own with the team (cloud, owner-only) |
-
-On a team cloud, `/entities` and `/graph` (and the queryable `/tables/*` allowlist) are filtered to the tables you own plus tables shared to the team — so the API surface matches exactly what the GUI shows; a table you can't see is not reachable. `/entities` rows carry `shared` / `ownedByMe` flags in that mode.
+| Route                          | Method | Lattice call                                                        |
+| ------------------------------ | ------ | ------------------------------------------------------------------- |
+| `/project`                     | GET    | (config + manifest summary)                                         |
+| `/entities`                    | GET    | tables + `db.count` per table                                       |
+| `/graph`                       | GET    | (schema graph for Data Model)                                       |
+| `/tables/:table/rows`          | GET    | `db.query(table, …)`                                                |
+| `/tables/:table/rows`          | POST   | `db.insert(table, body)`                                            |
+| `/tables/:table/rows/:id`      | GET    | `db.get(table, id)`                                                 |
+| `/tables/:table/rows/:id`      | PATCH  | `db.update(table, id, body)`                                        |
+| `/tables/:table/rows/:id`      | DELETE | `db.delete(table, id)`                                              |
+| `/tables/:junction/link`       | POST   | `db.link(junction, body)`                                           |
+| `/tables/:junction/unlink`     | POST   | `db.unlink(junction, body)`                                         |
+| `/schema/entities`             | POST   | create a new entity/table                                           |
+| `/schema/entities/:name/share` | POST   | share/unshare a table you own with the cloud workspace (owner-only) |
+
+On a cloud workspace, `/entities` and `/graph` (and the queryable `/tables/*` allowlist) are filtered to the tables you own plus tables shared to the workspace — so the API surface matches exactly what the GUI shows; a table you can't see is not reachable. `/entities` rows carry `shared` / `ownedByMe` flags in that mode.
 
 The server only binds to `127.0.0.1` and has no authentication. See [SECURITY.md](./SECURITY.md) for the threat model — do not expose this port to a non-loopback interface.
 
@@ -2312,7 +2323,7 @@ lattice teams dlq purge --team <name> [--id <id>] # discard without applying
 
 **Per-table ownership + opt-in sharing (v1.14+).** Team members share one physical Postgres, so visibility is enforced at the app layer via a `__lattice_object_owners` table: each table records its creator, and a user sees only the tables they own plus tables explicitly shared to the team. The native `files`/`secrets` objects are owned by the database creator and private by default. Sharing is an explicit, owner-only action (not a side effect of creating a table). The filter gates API access, not just the display.
 
-**Same flows from the GUI (v1.14+).** The local `lattice gui` drives the entire teams lifecycle from **Database Settings**: rename (owner-only), invite by email (owner-only), the inline Members list (the owner is always shown as `creator`; your own row offers Leave/Destroy; non-owners can't kick), share/unshare from the Data Model, and sync status. Member admin is resolved from `GET /api/dbconfig` against the active cloud DB, so it works even when the team cloud itself is the active database. Identity (display name + email) comes from `~/.lattice/identity.json` and is locked in the Join modal. Leaving a team removes the local config + credential and switches you to another database.
+**Same flows from the GUI (v1.14+).** The local `lattice gui` drives the entire cloud-workspace lifecycle from **Workspace Settings**: rename (owner-only), invite by email (owner-only), the inline Members list with pending invitees (the owner is always shown as `creator`; your own row offers Leave/Destroy; non-owners can't kick), share/unshare from the Data Model, and sync status. Member admin is resolved from `GET /api/dbconfig` against the active cloud DB, so it works even when the cloud workspace itself is the active database. Identity (display name + email) comes from `~/.lattice/identity.json` and is locked in the Join modal. Leaving a workspace removes the local config + credential and switches you to another database.
 
 **Joining via the GUI is one click (v1.13.7+).** When you click "Join via invite" and the redeem succeeds, the team's cloud URL is automatically saved as a switchable database credential and a sibling YAML config is written to your project directory. The new entry shows up in the database dropdown as `<team-name>.config`. Clicking it opens the SPA with the team's shared tables already populated — no YAML editing, no `db.define()` calls.
 
@@ -2327,11 +2338,11 @@ The full architecture, schema, and HTTP surface live in [docs/teams.md](./docs/t
 Lattice Teams + the GUI's Database panel now flow through a state machine:
 
 ```
-LOCAL  →  CLOUD CONNECTED  →  TEAM CLOUD
-       (migrate)           (upgrade)
+LOCAL  →  CLOUD WORKSPACE (owner | member | needs-invite)
+       (migrate / connect)
 ```
 
-Each transition is one-way: once on cloud, the panel does not surface a revert-to-local button. Disconnecting from the cloud temporarily is a follow-up; for v1.13 the in-place reconnection happens automatically when the GUI reopens.
+Migrating or connecting to Postgres produces a cloud workspace directly — its member/share machinery is initialized automatically, with no separate "upgrade" step (the intermediate `cloud-connected` state was removed in 1.16.3). The transition is one-way: once on cloud, the panel does not surface a revert-to-local button. Disconnecting from the cloud temporarily is a follow-up; the in-place reconnection happens automatically when the GUI reopens.
 
 Public API surface (the GUI's `/api/dbconfig/*` routes are thin wrappers):
 
@@ -2368,17 +2379,20 @@ await client.connectToExistingCloud({
   name: 'Bob',
 });
 
-// 4. Upgrade an already-connected cloud DB to a team cloud
-await client.upgradeToTeamCloud({
+// 4. Initialize the workspace member/share machinery on a cloud DB.
+//    The GUI now does this automatically on migrate/connect/open; the
+//    helper remains for programmatic use (idempotent — a no-op if the
+//    cloud is already a workspace).
+await client.ensureCloudWorkspaceIdentity({
   label: 'atlas',
   cloudUrl: 'postgres://u:p@host/db',
-  teamName: 'Atlas',
+  workspaceName: 'Atlas',
   email: 'alice@example.com',
   displayName: 'Alice',
 });
 ```
 
-GUI consumers don't need to call these directly — the Database panel surfaces them as wizards (`Migrate to cloud →`, `Connect to existing cloud →`, `Upgrade to team cloud →`).
+GUI consumers don't need to call these directly — the Database panel surfaces `Migrate to cloud →`, and joining a shared workspace goes through `Join a team (invite)`; workspace initialization is automatic. (The standalone "Connect to existing cloud" wizard was removed in 1.16.4.)
 
 HTTP surface (all under `/api/dbconfig/*`, localhost-only, same auth model as the rest of `lattice gui`):
 
@@ -2388,10 +2402,9 @@ HTTP surface (all under `/api/dbconfig/*`, localhost-only, same auth model as th
 | POST   | `/api/dbconfig/probe`                     | `probeCloud(url)`                             |
 | POST   | `/api/dbconfig/migrate-to-cloud`          | `migrateLatticeData` + `archiveLocalSqlite`   |
 | POST   | `/api/dbconfig/connect-existing`          | `TeamsClient.connectToExistingCloud`          |
-| POST   | `/api/dbconfig/upgrade-to-team`           | `TeamsClient.upgradeToTeamCloud`              |
 | POST   | `/api/dbconfig/save` / `connect` / `test` | unchanged from v1.12                          |
 
-The `state` field on `GET /api/dbconfig` is one of: `local`, `cloud-connected`, `team-cloud-creator`, `team-cloud-member`, `team-cloud-needs-invite`. The SPA badge color-codes them; the routes use them only for response shape.
+The `state` field on `GET /api/dbconfig` is one of: `local`, `team-cloud-creator`, `team-cloud-member`, `team-cloud-needs-invite` (the `cloud-connected` state was removed in 1.16.3). The SPA badge color-codes them (labeled "CLOUD · OWNER / MEMBER / NEEDS INVITE"); the routes use them only for response shape.
 
 ---