test(#30120): non-vacuity control on the config leak check; changesets

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WV4cyhB3ePno23ywn1PQd

Author: claude

.changeset/30120-console-deployment-notice.md

@@ -0,0 +1,12 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+---
+
+feat(console): administrators of a production deployment that keeps its data on its own disk see a standing notice on the home page and System Overview
+
+Clause-②: no
+Metadata-protocol: none
+
+- **`@object-ui/app-shell`.** The home page and Setup's System Overview open with a notice, for workspace administrators the server also admits, when the deployment reports what it keeps on its own disk (`GET /api/settings/deployment/notice`): the database file, the generated sign-in secret and the data key file, each in business terms with its path and variable, then the lower-severity lines for local uploads and no email service. "Copy the settings" puts the variables to set on the clipboard, each with the value it takes (the file to carry the current value over from). "Hide" records the acknowledgement on the server's audit log and keeps the notice hidden for that administrator in that browser until the findings change; System Overview then keeps one small line with "Show again". No dialog; a member's browser never asks.
+- **`@object-ui/i18n`.** A new `deploymentNotice` block (19 keys) in all ten packs.

.changeset/30120-image-refuses-undurable-start.md

@@ -0,0 +1,13 @@
+---
+'@objectstack/cli': patch
+'@objectstack/service-settings': patch
+---
+
+fix(cli): the official image refuses to start on a disk it would lose; every other production `os start` says what it keeps there, and administrators see it in the Console
+
+Clause-②: no
+Metadata-protocol: none
+
+- **`@objectstack/cli` (the official image).** With `OS_DEPLOYMENT_DURABILITY_CHECK_ENABLED=true`, which the official image now sets in its `ENV`, `os start` exits 1 unless `OS_DATABASE_URL`, `OS_AUTH_SECRET` and `OS_SECRET_KEY` are all set explicitly (their legacy names count, and so do `--database` / `--auth-secret` and a database the project config declares). It names the missing ones before it writes a database file or a secret, and says how a deployment already running on generated values carries them over: the files in the container's home, and which of them the container holds. An explicit `OS_DATABASE_URL=file:/path/on/a/volume/app.db` passes. A value of the switch that is not `true`/`false`/`1`/`0` is refused rather than read as off. **Upgrading an image deployment that ran on its defaults:** read `auth-secret` and `dev-crypto-key` (and `data/objectstack.db`) out of the old container's `/home/node/.objectstack` and set them before you start the new one.
+- **`@objectstack/cli` (every other `os start`).** Unchanged: it keeps booting. In production mode, when it keeps its database, its sign-in secret or its data key on its own disk because nobody set them, it prints a block naming each file and the variable that moves it off that disk, and hands the same facts to the server process on the internal `OS_INTERNAL_DEPLOYMENT_FINDINGS` channel.
+- **`@objectstack/service-settings`.** Two routes behind the settings door, for callers holding `manage_platform_settings`: `GET /api/settings/deployment/notice` answers what this production deployment keeps on its own disk (the database file, the generated sign-in secret, the data key file) plus two lower-severity lines (uploads on the local disk; no email service that delivers), and `POST /api/settings/deployment/notice/hide` records an administrator's acknowledgement of exactly what they read as a `config_change` row on `sys_audit_log`. A member is refused `403`, the state is not on the public auth config, a hide is refused `409` where no audit log is mounted or the notice changed since it was read, and outside production mode the notice is empty. No package export is added.

packages/cli/test/start-deployment-durability.integration.test.ts

@@ -409,10 +409,15 @@ describe('#30120 — without the switch, a production start on its defaults boot
   });
 
   it('neither the public auth config nor the runtime config carries the notice', () => {
-    const { authConfig, runtimeConfig, home } = recorded();
+    const { authConfig, runtimeConfig, adminNotice, home } = recorded();
+    // Non-vacuity: the administrator's own read carries every string the
+    // check below looks for, so a leak of it could not pass unseen.
+    for (const leak of ['database_local_file', 'auth_secret_generated', 'data_key_file', home]) {
+      expect(adminNotice.text).toContain(leak);
+    }
     for (const served of [authConfig, runtimeConfig]) {
       expect(served.status, served.text.slice(0, 500)).toBe(200);
-      for (const leak of ['database_local_file', 'auth_secret_generated', 'data_key_file', 'deploymentNotice', home]) {
+      for (const leak of ['database_local_file', 'auth_secret_generated', 'data_key_file', 'deployment_notice', home]) {
         expect(served.text).not.toContain(leak);
       }
     }