chore(deps): upgrade @objectstack to 8.0.1 and bump ObjectOS One to 8.0.1 (#19)

Bump all @objectstack/* dependencies in @objectos/server from ^7.9.0 to
^8.0.1 and refresh the lockfile. 8.0 is a major: the runtime removed the
cloud-connected, hostname-routed createObjectOSStack wrapper, so
apps/objectos/objectstack.config.ts is migrated to the single-tenant
createStandaloneStack host (OS_ARTIFACT_FILE → artifactPath, which now
also accepts an http(s):// cloud artifact URL; OS_BUSINESS_DB_URL →
databaseUrl). The cli-internal @objectstack/plugin-mcp-server → @objectstack/mcp
rename does not affect ObjectOS (no direct import).

Propagate the resolved cli version (8.0.1) to apps/objectos-one
package.json, tauri.conf.json, Cargo.toml and Cargo.lock via sync-version.
type-check passes; smoke test boots clean on 8.0.1 (26 plugins, HTTP ready).

Docs: scan the framework changesets for the real 8.0 surface and update the
official site — changelog (MCP over HTTP, self-serve API keys, field
conditional rules, RLS read filter, standalone host), environment-variables
(OS_MCP_SERVER_ENABLED, corrected artifact/cloud wording, artifact HMR via
NODE_ENV), and api-access (POST /api/v1/keys, x-api-key / Authorization: ApiKey,
/api/v1/mcp). English + all six translations (de/es/fr/ja/ko/zh-Hans).

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: os-zhuang

apps/objectos-one/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@objectos/one",
-  "version": "7.9.0",
+  "version": "8.0.1",
   "private": true,
   "license": "Apache-2.0",
   "description": "ObjectOS One — all-in-one local distribution (Tauri shell + bundled Node runtime + DB).",

apps/objectos-one/src-tauri/Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "objectos-one"
-version = "7.9.0"
+version = "8.0.1"
 description = "ObjectOS One shell"
 edition = "2021"
 rust-version = "1.77"

apps/objectos-one/src-tauri/Cargo.toml

@@ -1,7 +1,7 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "ObjectOS",
-  "version": "7.9.0",
+  "version": "8.0.1",
   "identifier": "ai.objectstack.objectos",
   "build": {
     "frontendDist": "../src",

apps/objectos-one/src-tauri/tauri.conf.json

@@ -6,34 +6,38 @@
  * `@objectstack/*` packages on npm; this repository deliberately
  * contains no protocol code of its own.
  *
- * Boot mode is governed by environment variables:
+ * As of @objectstack 8.0 the runtime ships a single-tenant *standalone*
+ * stack (`createStandaloneStack`); the 7.x cloud-connected, hostname-routed
+ * multi-tenant wrapper (`createObjectOSStack`) has been removed from the
+ * public runtime API. A cloud deployment now points `OS_ARTIFACT_FILE` at a
+ * published artifact URL — `artifactPath` accepts `http(s)://` sources and
+ * is fetched lazily by the loader.
  *
- *   OS_CLOUD_URL        — Artifact API base URL (cloud-connected mode)
- *   OS_ENVIRONMENT_ID   — Environment/project to serve (legacy: OS_PROJECT_ID)
- *   OS_ARTIFACT_FILE    — Path to a local dist/objectstack.json (offline mode)
- *   OS_BUSINESS_DB_URL  — Per-project business database
- *   OS_CACHE_DIR        — Local artifact cache (default: /var/cache/objectos)
+ * Boot is governed by environment variables (all optional — sensible
+ * defaults are applied by `createStandaloneStack`):
  *
- * If OS_CLOUD_URL is absent, ObjectOS defaults to local file-backed mode.
- * Enterprise plugins live in ../../packages/* and can be appended to the
- * default plugin manifest below.
+ *   OS_ARTIFACT_FILE    — Path or URL to a compiled `dist/objectstack.json`
+ *                         (default: <cwd>/dist/objectstack.json)
+ *   OS_ENVIRONMENT_ID   — Environment/project to serve (legacy: OS_PROJECT_ID;
+ *                         default: proj_local)
+ *   OS_BUSINESS_DB_URL  — Per-project business database (legacy: OS_DATABASE_URL;
+ *                         default: file-backed sqlite under the ObjectStack home)
+ *
+ * Artifact hot-reload follows `NODE_ENV` (on outside production). Enterprise
+ * plugins live in ../../packages/* and can be appended to the returned
+ * plugin manifest below.
  */
 
-import { createObjectOSStack } from '@objectstack/runtime';
+import { createStandaloneStack } from '@objectstack/runtime';
 
-const cloudUrl = process.env.OS_CLOUD_URL;
 const artifactFile = process.env.OS_ARTIFACT_FILE;
 const environmentId =
   process.env.OS_ENVIRONMENT_ID ?? process.env.OS_PROJECT_ID;
+const databaseUrl =
+  process.env.OS_BUSINESS_DB_URL ?? process.env.OS_DATABASE_URL;
 
-export default await createObjectOSStack({
-  controlPlaneUrl: cloudUrl ?? 'file',
-  controlPlaneApiKey: process.env.OS_CLOUD_API_KEY,
-  fileConfig: artifactFile
-    ? {
-        artifactPath: artifactFile,
-        environmentId,
-        watch: process.env.OS_WATCH_ARTIFACT === '1',
-      }
-    : undefined,
+export default await createStandaloneStack({
+  artifactPath: artifactFile,
+  environmentId,
+  databaseUrl,
 });

apps/objectos/objectstack.config.ts

@@ -13,14 +13,14 @@
     "type-check": "tsc --noEmit"
   },
   "dependencies": {
-    "@objectstack/cli": "^7.9.0",
-    "@objectstack/core": "^7.9.0",
-    "@objectstack/driver-memory": "^7.9.0",
-    "@objectstack/driver-sql": "^7.9.0",
-    "@objectstack/metadata": "^7.9.0",
-    "@objectstack/objectql": "^7.9.0",
-    "@objectstack/runtime": "^7.9.0",
-    "@objectstack/spec": "^7.9.0"
+    "@objectstack/cli": "^8.0.1",
+    "@objectstack/core": "^8.0.1",
+    "@objectstack/driver-memory": "^8.0.1",
+    "@objectstack/driver-sql": "^8.0.1",
+    "@objectstack/metadata": "^8.0.1",
+    "@objectstack/objectql": "^8.0.1",
+    "@objectstack/runtime": "^8.0.1",
+    "@objectstack/spec": "^8.0.1"
   },
   "devDependencies": {
     "@types/node": "^25.9.1",

apps/objectos/package.json

@@ -25,6 +25,8 @@ Wichtige Schnittstellen:
 | `/api/v1/actions/<object>/<action>` | Eine deklarative Aktion aufrufen (POST) |
 | `/api/v1/auth/*` | Authentifizierung (Anmeldung, Sitzungen, OAuth, OIDC) |
 | `/api/v1/meta/*` | Metadaten-APIs (Objekte, Felder, Ansichten), sofern aktiviert |
+| `/api/v1/keys` | Erzeugt einen nur einmal angezeigten `sys_api_key` für den aufrufenden Benutzer (POST) |
+| `/api/v1/mcp` | Model-Context-Protocol-Server über Streamable HTTP, wenn `OS_MCP_SERVER_ENABLED=true` |
 | `/api/v1/health` | Liveness-/Readiness-Probe (keine Authentifizierung) |
 
 Das Präfix lautet standardmäßig `/api/v1` (der API-`basePath` von `/api` plus
@@ -51,20 +53,32 @@ selbst wird gehasht gespeichert — nur das `prefix` und Metadaten bleiben
 abfragbar, sodass ein durchgesickerter Schlüssel nicht aus der Datenbank
 rekonstruiert werden kann.
 
-So stellen Sie einen Schlüssel aus:
-
-1. Melden Sie sich als Administrator bei **Console → API Keys** an.
-2. Wählen Sie den besitzenden Benutzer (der API-Aufruf erbt die
-   Berechtigungen und den Datensatzzugriff dieses Benutzers).
-3. Legen Sie optional ein Ablaufdatum fest.
-4. Kopieren Sie das angezeigte Geheimnis **einmalig** — es wird nicht erneut
-   angezeigt.
-
-Verwenden Sie den Schlüssel als Bearer-Token:
+Es gibt zwei Wege, einen Schlüssel auszustellen:
+
+- **Console** — melden Sie sich als Administrator bei **Console → API Keys**
+  an, wählen Sie den besitzenden Benutzer, legen Sie optional ein Ablaufdatum
+  fest und kopieren Sie das angezeigte Geheimnis **einmalig**.
+- **Self-Service-Endpunkt** — `POST /api/v1/keys` erzeugt einen Schlüssel für
+  den authentifizierten Aufrufer und gibt das rohe Geheimnis genau einmal
+  zurück. Der Schlüssel ist an den eigenen Benutzer des Aufrufers gebunden und
+  kann daher nicht zur Identitätsübernahme verwendet werden:
+
+  ```bash
+  curl -X POST https://app.example.com/api/v1/keys \
+    -H "Authorization: Bearer <session-or-access-token>" \
+    -H "Content-Type: application/json" \
+    -d '{"name": "etl-pipeline"}'
+  # → { "id": "...", "name": "etl-pipeline", "prefix": "os_pk_…", "key": "os_pk_live_…" }
+  ```
+
+Übergeben Sie den Schlüssel bei nachfolgenden Anfragen als Bearer-Token, als
+`x-api-key`-Header oder als `Authorization: ApiKey`. Die REST-Daten- und
+Metadaten-APIs authentifizieren ihn über denselben Verifier wie MCP, unter den
+Berechtigungen und der Datensatz-Sicherheit des Schlüsselinhabers:
 
 ```bash
 curl https://app.example.com/api/v1/data/account \
-  -H "Authorization: Bearer os_pk_live_…"
+  -H "x-api-key: os_pk_live_…"
 ```
 
 Um einen Schlüssel zu widerrufen, führen Sie die Aktion `revoke_api_key` für

content/docs/configure/api-access.de.mdx

@@ -25,6 +25,8 @@ Superficies destacadas:
 | `/api/v1/actions/<object>/<action>` | Invocar una acción declarativa (POST) |
 | `/api/v1/auth/*` | Autenticación (inicio de sesión, sesiones, OAuth, OIDC) |
 | `/api/v1/meta/*` | APIs de metadatos (objetos, campos, vistas) cuando está habilitado |
+| `/api/v1/keys` | Genera un `sys_api_key` de un solo uso para el usuario que llama (POST) |
+| `/api/v1/mcp` | Servidor Model Context Protocol sobre Streamable HTTP, cuando `OS_MCP_SERVER_ENABLED=true` |
 | `/api/v1/health` | Sonda de liveness/readiness (sin autenticación) |
 
 El prefijo es `/api/v1` de forma predeterminada (el `basePath` de la API,
@@ -51,19 +53,32 @@ de la clave en sí se almacena cifrado (hash) — solo el `prefix` y los
 metadatos permanecen consultables, de modo que una clave filtrada no puede
 reconstruirse a partir de la base de datos.
 
-Para emitir una clave:
-
-1. Inicia sesión en **Console → API Keys** como administrador.
-2. Elige el usuario propietario (la llamada a la API hereda los permisos
-   y el acceso a registros de ese usuario).
-3. Opcionalmente, establece una fecha de expiración.
-4. Copia el secreto mostrado **una sola vez** — no se vuelve a mostrar.
-
-Usa la clave como token bearer:
+Emite una clave de dos maneras:
+
+- **Console** — inicia sesión en **Console → API Keys** como administrador,
+  elige el usuario propietario, opcionalmente establece una fecha de
+  expiración y copia el secreto mostrado **una sola vez**.
+- **Endpoint de autoservicio** — `POST /api/v1/keys` genera una clave para el
+  llamante autenticado y devuelve el secreto en bruto exactamente una vez. La
+  clave queda fijada al propio usuario del llamante, por lo que no puede usarse
+  para suplantar otra identidad:
+
+  ```bash
+  curl -X POST https://app.example.com/api/v1/keys \
+    -H "Authorization: Bearer <session-or-access-token>" \
+    -H "Content-Type: application/json" \
+    -d '{"name": "etl-pipeline"}'
+  # → { "id": "...", "name": "etl-pipeline", "prefix": "os_pk_…", "key": "os_pk_live_…" }
+  ```
+
+Pasa la clave en las solicitudes posteriores como token bearer, como cabecera
+`x-api-key` o como `Authorization: ApiKey`. Las API REST de datos y metadatos
+la autentican con el mismo verificador que MCP, bajo los permisos y la
+seguridad a nivel de registro del propietario de la clave:
 
 ```bash
 curl https://app.example.com/api/v1/data/account \
-  -H "Authorization: Bearer os_pk_live_…"
+  -H "x-api-key: os_pk_live_…"
 ```
 
 Para revocar una clave, ejecuta la acción `revoke_api_key` en el registro

content/docs/configure/api-access.es.mdx

@@ -25,6 +25,8 @@ Surfaces notables :
 | `/api/v1/actions/<object>/<action>` | Invoquer une action déclarative (POST) |
 | `/api/v1/auth/*` | Authentification (connexion, sessions, OAuth, OIDC) |
 | `/api/v1/meta/*` | API de métadonnées (objets, champs, vues) lorsqu'elles sont activées |
+| `/api/v1/keys` | Génère une `sys_api_key` affichée une seule fois pour l'utilisateur appelant (POST) |
+| `/api/v1/mcp` | Serveur Model Context Protocol via Streamable HTTP, lorsque `OS_MCP_SERVER_ENABLED=true` |
 | `/api/v1/health` | Sonde de vivacité/disponibilité (sans authentification) |
 
 Le préfixe est `/api/v1` par défaut (le `basePath` de l'API `/api` plus la
@@ -51,20 +53,34 @@ valeur de la clé elle-même est stockée hachée — seuls le `prefix` et les
 métadonnées restent interrogeables, de sorte qu'une clé divulguée ne peut
 pas être reconstituée à partir de la base de données.
 
-Pour émettre une clé :
-
-1. Connectez-vous à **Console → API Keys** en tant qu'administrateur.
-2. Choisissez l'utilisateur propriétaire (l'appel API hérite des
-   permissions et de l'accès aux enregistrements de cet utilisateur).
-3. Définissez éventuellement une date d'expiration.
-4. Copiez le secret affiché **une seule fois** — il n'est plus affiché par
-   la suite.
-
-Utilisez la clé comme jeton bearer :
+Émettez une clé de deux façons :
+
+- **Console** — connectez-vous à **Console → API Keys** en tant
+  qu'administrateur, choisissez l'utilisateur propriétaire, définissez
+  éventuellement une date d'expiration et copiez le secret affiché **une seule
+  fois**.
+- **Endpoint en libre-service** — `POST /api/v1/keys` génère une clé pour
+  l'appelant authentifié et renvoie le secret brut exactement une fois. La clé
+  est rattachée au propre utilisateur de l'appelant et ne peut donc pas servir
+  à usurper une autre identité :
+
+  ```bash
+  curl -X POST https://app.example.com/api/v1/keys \
+    -H "Authorization: Bearer <session-or-access-token>" \
+    -H "Content-Type: application/json" \
+    -d '{"name": "etl-pipeline"}'
+  # → { "id": "...", "name": "etl-pipeline", "prefix": "os_pk_…", "key": "os_pk_live_…" }
+  ```
+
+Passez la clé sur les requêtes suivantes comme jeton bearer, comme en-tête
+`x-api-key` ou comme `Authorization: ApiKey`. Les API REST de données et de
+métadonnées l'authentifient via le même vérificateur que MCP, sous les
+permissions et la sécurité au niveau des enregistrements du propriétaire de la
+clé :
 
 ```bash
 curl https://app.example.com/api/v1/data/account \
-  -H "Authorization: Bearer os_pk_live_…"
+  -H "x-api-key: os_pk_live_…"
 ```
 
 Pour révoquer une clé, exécutez l'action `revoke_api_key` sur

content/docs/configure/api-access.fr.mdx

@@ -24,6 +24,8 @@ https://<project-domain>/api/v1
 | `/api/v1/actions/<object>/<action>` | 宣言的アクションの呼び出し（POST） |
 | `/api/v1/auth/*` | 認証（サインイン、セッション、OAuth、OIDC） |
 | `/api/v1/meta/*` | 有効化されている場合のメタデータ API（オブジェクト、フィールド、ビュー） |
+| `/api/v1/keys` | 呼び出しユーザー向けに一度だけ表示される `sys_api_key` を発行（POST） |
+| `/api/v1/mcp` | `OS_MCP_SERVER_ENABLED=true` のとき、Streamable HTTP 経由の Model Context Protocol サーバー |
 | `/api/v1/health` | 死活／準備状態のプローブ（認証不要） |
 
 プレフィックスのデフォルトは `/api/v1`（API の `basePath` である `/api` と
@@ -48,19 +50,32 @@ API キーはファーストクラスの `sys_api_key` レコードです。キ
 ハッシュ化して保存され、クエリ可能なのは `prefix` とメタデータのみです。
 そのため、漏洩したキーをデータベースから復元することはできません。
 
-キーを発行するには:
-
-1. 管理者として **Console → API Keys** にサインインします。
-2. 所有ユーザーを選択します（API 呼び出しはそのユーザーの権限と
-   レコードアクセスを継承します）。
-3. 必要に応じて有効期限を設定します。
-4. 表示されたシークレットを**一度だけ**コピーします。再表示はされません。
-
-キーは bearer トークンとして使用します:
+キーは次の 2 つの方法で発行できます:
+
+- **Console** — 管理者として **Console → API Keys** にサインインし、所有
+  ユーザーを選択し、必要に応じて有効期限を設定して、表示されたシークレットを
+  **一度だけ**コピーします。
+- **セルフサービスエンドポイント** — `POST /api/v1/keys` は認証済みの呼び出し元
+  に対してキーを発行し、生のシークレットをちょうど一度だけ返します。キーは
+  呼び出し元自身のユーザーに固定されるため、別の ID へのなりすましには使用
+  できません:
+
+  ```bash
+  curl -X POST https://app.example.com/api/v1/keys \
+    -H "Authorization: Bearer <session-or-access-token>" \
+    -H "Content-Type: application/json" \
+    -d '{"name": "etl-pipeline"}'
+  # → { "id": "...", "name": "etl-pipeline", "prefix": "os_pk_…", "key": "os_pk_live_…" }
+  ```
+
+以降のリクエストでは、キーを bearer トークン、`x-api-key` ヘッダー、または
+`Authorization: ApiKey` として渡します。REST のデータ／メタデータ API はいずれも
+MCP と同じ検証器で認証し、キー所有者の権限とレコードレベルセキュリティの下で
+実行されます:
 
 ```bash
 curl https://app.example.com/api/v1/data/account \
-  -H "Authorization: Bearer os_pk_live_…"
+  -H "x-api-key: os_pk_live_…"
 ```
 
 キーを失効させるには、対応する `sys_api_key` レコードに対して