fix(service-settings,cloud-connection)!: Branding settings drive runtime-config under single; theme_mode and support_email retire; namespace withheld under walled postures

.changeset/24766-auth-brand-binding.md

@@ -0,0 +1,18 @@
+---
+'@objectstack/plugin-auth': minor
+---
+
+fix(plugin-auth): the auth product name binds to `branding.workspace_name` only where the settings service offers the `branding` namespace, so a walled boot no longer warns about it
+
+Clause-②: no (this package stops reading a namespace `@objectstack/service-settings` no longer offers under a wall; that withholding, declared BREAKING in its changeset, is what narrows the walled deployment, and nothing here widens)
+
+`AuthPlugin` binds the product name in sign-in emails, the authenticator app entry and the MCP sign-in to the `branding.workspace_name` setting. `@objectstack/service-settings` (same release) no longer offers the `branding` namespace under the `group` and `isolated` tenancy postures, so on such a deployment that read would fail on every boot and log `Auth: failed to apply branding.workspace_name: No settings manifest registered for namespace 'branding'.` at `warn`.
+
+The binding is now made only when the settings service lists the `branding` namespace, the same test the runtime config makes. On a single-organization deployment a saved name, or one pinned with `OS_BRANDING_WORKSPACE_NAME`, applies as before.
+
+**On a walled deployment (`group` / `isolated`) the auth product name now comes from the `OS_APP_NAME` chain alone.** Nothing is read from the `branding` namespace and nothing is logged. Two sources that used to name sign-in emails, the authenticator issuer and the MCP sign-in there stop doing so:
+
+- `OS_BRANDING_WORKSPACE_NAME`. The settings service served it as an `env` value whatever the posture, and this plugin applied it.
+- A `branding.workspace_name` row stored with no organization, for example one saved before the wall stood.
+
+Migration, FROM → TO: `OS_BRANDING_WORKSPACE_NAME=Acme` → `OS_APP_NAME=Acme`. Set `OS_APP_NAME` to the name the deployment's sign-in emails and authenticator entries should carry. A deployment that set neither source sees no change.

.changeset/24766-branding-settings-v2.md

@@ -0,0 +1,37 @@
+---
+'@objectstack/service-settings': minor
+---
+
+fix(service-settings)!: the Branding settings drive the console's name, logo and colour on a single-organization deployment, retire `theme_mode` and `support_email`, and are not offered under a walled tenancy posture
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) The two retired keys were settings values, not metadata: only the platform-shipped brandingSettingsManifest declared them (only platform code declares a settings manifest), SettingsManifestSchema and every other spec declaration are unchanged, and a value stored for one of them lives in sys_setting (runtime state, ADR-0007), not sys_metadata, and is kept as it is. Nothing read either key in objectstack or in objectui at the console pin, so no consumer has anything to rewrite and objectstack migrate meta has nothing to reach. Withholding the branding namespace under a walled posture moves no stored row either. The one operator-facing consequence there, that OS_BRANDING_WORKSPACE_NAME stops naming sign-in mail and the OS_APP_NAME variable takes its place, is a deployment environment setting: no consumer code and no metadata is rewritten, so the ledger has nothing to carry and objectstack migrate meta nothing to reach. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id covers a settings key (not already-registered); and the change is the value of an exported manifest constant and the plugin's registration behaviour, not an interface or a type alone (not runtime-interface-only or type-surface-only). -->
+
+Setup → Branding saved values that nothing in the console ever read. Under the maintainer's ruling, its three keys now drive the console's own branding through the runtime config (`@objectstack/cloud-connection`, same release), the two keys with no counterpart retire, and the page is offered only where no organization wall stands.
+
+**What the three keys do now** (a single-organization deployment, the `single` posture):
+
+- `workspace_name` is the product name in the console, on the sign-in page and in the browser title, and it stays the product name in sign-in emails, the authenticator app and MCP sign-in.
+- `logo_url` is the logo on the sign-in page, the loading screen and the home header.
+- `accent_color` is the browser and installed-app theme colour. Each app keeps the colours its own `AppBranding` declares.
+- A key nobody set falls back to the deployment's own branding (`OS_PRODUCT_NAME`, `OS_LOGO_URL`, `OS_BRAND_COLOR`, or the host's `RuntimeConfigPlugin` options). A value pinned with the settings layer's `OS_BRANDING_WORKSPACE_NAME`, `OS_BRANDING_LOGO_URL` or `OS_BRANDING_ACCENT_COLOR` counts as set. A save shows on the next page load, with no restart. `accent_color` no longer declares the `#6366f1` default, which the page showed as a colour the console never used.
+
+**BREAKING: `theme_mode` and `support_email` are retired.** The Branding manifest (`brandingSettingsManifest`) drops both specifiers and their copy in the `en`, `zh-CN`, `ja-JP` and `es-ES` settings bundles, and its `version` is now 2, as the `SettingsManifest.version` contract asks when keys are removed. Nothing ever read either key. A value a workspace already stored is kept:
+
+- The `sys_setting` row stays exactly as it was. No read or save rewrites or deletes it, and it never blocks saving the live keys.
+- `GET /api/settings/branding` does not resolve it: the key is absent from both `manifest.specifiers` and `values`.
+- A `PUT /api/settings/branding` that names `theme_mode` or `support_email` is refused with `400 UNKNOWN_KEY` (`details.key` names it). The refusal covers the whole batch, so a live key sent beside it does not land either.
+- `OS_BRANDING_THEME_MODE` and `OS_BRANDING_SUPPORT_EMAIL` are no longer read on any deployment.
+
+**BREAKING: under the `group` and `isolated` postures the Branding namespace is not offered.** It is absent from `GET /api/settings`, `GET` or `PUT /api/settings/branding` is refused with `404 UNKNOWN_NAMESPACE`, the answer every unknown namespace gets, and Setup lists no Branding entry: `SettingsServicePlugin` now contributes the `nav_settings_branding` Setup entry itself, with the namespace, so the entry exists exactly where the page does. The runtime config is an anonymous door that resolves no organization before sign-in, so on a walled deployment the branding is the operator's: the console's through `OS_PRODUCT_NAME`, `OS_LOGO_URL` and `OS_BRAND_COLOR`, and the auth product name through `OS_APP_NAME`.
+
+**On a walled deployment the `OS_BRANDING_*` variables are no longer read.** With the namespace withheld, none of `OS_BRANDING_WORKSPACE_NAME`, `OS_BRANDING_LOGO_URL` and `OS_BRANDING_ACCENT_COLOR` reaches a reader there. One of them had an effect before this release: `OS_BRANDING_WORKSPACE_NAME` named sign-in emails, the authenticator issuer and the MCP sign-in (`@objectstack/plugin-auth` applied it as an `env` value whatever the posture). So did a `branding.workspace_name` row stored with no organization. Both now give way to the `OS_APP_NAME` chain. The fix is in the deployment's environment, not in any code or metadata: a walled deployment that set `OS_BRANDING_WORKSPACE_NAME=Acme` sets `OS_APP_NAME=Acme` instead. The other two variables had no reader before and have none on a walled deployment now. A value already stored is kept and is offered again if the deployment returns to `single`. A host that passes its own `branding` manifest through `SettingsServicePlugin({ manifests })` gets the same rule.
+
+**What to do after upgrading.**
+
+- On a single-organization deployment nothing has to be rewritten.
+- There is no replacement for `theme_mode` (the console follows the user's own theme choice) or for `support_email`.
+- On a walled deployment, set the console's branding with `OS_PRODUCT_NAME`, `OS_LOGO_URL` and `OS_BRAND_COLOR`. If you set `OS_BRANDING_WORKSPACE_NAME` there, move its value to `OS_APP_NAME`.
+
+It ships as `minor` under the launch-window convention for narrowings.

.changeset/24766-runtime-config-branding-settings.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/cloud-connection': minor
+---
+
+feat(cloud-connection): `GET /api/v1/runtime/config` serves the Branding settings' name, logo and colour, falling back to `OS_PRODUCT_NAME`, `OS_LOGO_URL` and `OS_BRAND_COLOR`
+
+Clause-②: no (the served `branding` block keeps its shape and no exported type changes; only where its values come from moves)
+
+`RuntimeConfigPlugin` reads the `branding` settings namespace on every request, so Setup → Branding changes the console and the sign-in page on their next load:
+
+- `branding.productName` ← `branding.workspace_name`
+- `branding.logoUrl` ← `branding.logo_url`
+- `branding.brandColor` ← `branding.accent_color`
+
+A value somebody set wins (saved in Setup, or pinned by the settings layer's own `OS_BRANDING_*` variable). A key nobody set falls back exactly as before: the host's constructor option, then `OS_PRODUCT_NAME` / `OS_LOGO_URL` / `OS_BRAND_COLOR`, then the built-in default. `productShortName`, `pwaDescription` and `pwaThemeColor` follow the name and colour actually served, unless configured themselves. `brandColor` keeps its meaning: the console's browser and installed-app theme colour, beside each app's own `AppBranding` colours.
+
+The door reads the settings only when the settings service lists the `branding` namespace. `@objectstack/service-settings` withholds it under the `group` and `isolated` tenancy postures, so on a walled deployment no tenant data reaches this anonymous door and the deployment's `OS_*` branding is served, as before. A settings read that fails serves the deployment's branding and logs one warning; the door never answers 500 for it.

.changeset/24766-setup-branding-entry.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/platform-objects': minor
+---
+
+fix(platform-objects): `SETUP_NAV_CONTRIBUTIONS` no longer carries the Setup → Branding entry; `@objectstack/service-settings` contributes it with the `branding` namespace
+
+Clause-②: no (the entry moves to the package that serves its page: a composition that serves Setup → Branding still lists it, and one that does not no longer lists a page it cannot open)
+
+The `nav_settings_branding` entry (Setup → Configuration → Branding) was a static item of `SETUP_NAV_CONTRIBUTIONS`, listed whatever the settings service offered. From this release `@objectstack/service-settings` does not offer the `branding` namespace under the `group` and `isolated` tenancy postures, so a static entry would open a page the server refuses with `404 UNKNOWN_NAMESPACE`.
+
+`SettingsServicePlugin` (`@objectstack/service-settings`, same release) now contributes the entry from the same `kernel:ready` step that offers the namespace, and only then. On a single-organization deployment Setup still lists Branding, now at the end of the Configuration group's platform entries. Its translated labels are unchanged and still keyed `apps.setup.navigation.nav_settings_branding`.

content/docs/ui/setup-app.mdx

@@ -52,7 +52,7 @@ anchors are:
 | **People & Organization** (`group_people_org`) | Users · Organization · Business Units · Teams · Organizations · Invitations — `platform-objects` |
 | **Access Control** (`group_access_control`) | Positions / Permission Sets — `plugin-security`; Sharing Rules / Record Shares — `plugin-sharing`; API Keys — `platform-objects` |
 | **Approvals** (`group_approvals`) | Approvals Inbox (the `approvals:inbox` component) · Requests · Action History · Delegations (OOO) — `plugin-approvals` |
-| **Configuration** (`group_configuration`) | All Settings · Localization · Company · Branding · Authentication · Email · File Storage · AI & Embedder · Knowledge · Feature Flags — `platform-objects` |
+| **Configuration** (`group_configuration`) | All Settings · Localization · Company · Authentication · Email · File Storage · AI & Embedder · Knowledge · Feature Flags — `platform-objects`; Branding — `service-settings`, only where the `branding` settings namespace is offered (the `single` tenancy posture) |
 | **Diagnostics** (`group_diagnostics`) | Sessions · Notification Events — `platform-objects`; Audit Log — `plugin-audit` |
 | **Integrations** (`group_integrations`) | `plugin-webhooks` |
 | **Advanced** (`group_advanced`) | OAuth Applications — `platform-objects` |

packages/cli/scripts/check-app-nav-i18n.mjs

@@ -368,6 +368,41 @@ const CONTRIBUTORS = [
       return { plugin: new DatasourceAdminServicePlugin({}) };
     },
   },
+  {
+    // `nav_settings_branding` (#24766). The plugin contributes it from its
+    // `kernel:ready` hook, and only where no organization wall stands, so this
+    // entry boots it through init → start → kernel:ready on a context of its
+    // own that captures `kernel:ready` — the shared context below fires no
+    // hooks — with no `tenancy` service, which is the `single` reading, and
+    // returns what it registered.
+    source: '@objectstack/service-settings (Setup entries of the single-posture namespaces)',
+    apps: ['setup'],
+    async load() {
+      const { SettingsServicePlugin } = await import('@objectstack/service-settings');
+      const manifests = [];
+      const ready = [];
+      const own = {
+        getService: (name) => {
+          if (name === 'manifest') return { register: (m) => manifests.push(m) };
+          throw new Error(`Service '${name}' not found`);
+        },
+        registerService: () => {},
+        registerServiceFactory: () => {},
+        replaceService: () => {},
+        getServiceScoped: async () => undefined,
+        getServices: () => new Map(),
+        hook: (name, fn) => { if (name === 'kernel:ready') ready.push(fn); },
+        trigger: async () => {},
+        logger: { info: () => {}, warn: () => {}, error: () => {}, debug: () => {} },
+        getKernel: () => undefined,
+      };
+      const plugin = new SettingsServicePlugin({ env: {}, registerRoutes: false });
+      await plugin.init(own);
+      await plugin.start(own);
+      for (const fn of ready) await fn();
+      return { manifests };
+    },
+  },
   {
     source: '@objectstack/mcp (CONNECT_AGENT_UI_BUNDLE)',
     // The one contributor that lands in BOTH apps: `CONNECT_AGENT_UI_BUNDLE`

packages/cli/test/connect-agent-both-halves-wire.pin.test.ts

@@ -252,10 +252,17 @@ describe('#17647 — Connect-an-Agent visibility: BOTH halves, over the wire', (
         expect(allowedIds).toContain('nav_connect_agent');
         expect(groupChildren(setupAllowed.body?.item, 'group_integrations'))
             .toContain('nav_connect_agent');
-        // The Setup tree the platform admin is served: 9 authored groups less
-        // `group_approvals`, which nothing contributes into and the filter
-        // collapses, plus 23 contributed entries plus the MCP one.
-        expect(allowedIds).toHaveLength(32);
+        // The Setup tree the platform admin is served BY THIS COMPOSITION: 9
+        // authored groups less `group_approvals`, which nothing contributes
+        // into and the filter collapses, plus the 22 entries
+        // `SETUP_NAV_CONTRIBUTIONS` carries, plus the MCP one.
+        // `nav_settings_branding` is not among them, and not because of a
+        // tenancy wall (this harness boots none): since #24766 it is
+        // contributed by `@objectstack/service-settings` together with the
+        // `branding` namespace, offered only where no organization wall stands,
+        // and this harness composes platform-objects and the MCP bundle alone.
+        expect(allowedIds).toHaveLength(31);
+        expect(allowedIds).not.toContain('nav_settings_branding');
         // The two per-user stores are reached from the User record page, not
         // from Setup's menu (#23803).
         expect(allowedIds).not.toContain('nav_accounts');
@@ -277,7 +284,8 @@ describe('#17647 — Connect-an-Agent visibility: BOTH halves, over the wire', (
         expect(withAccountHalf.statusCode).toBe(200);
         expect(withoutAccountHalf.statusCode).toBe(200);
         expect(navIds(withAccountHalf.body?.item)).toEqual(navIds(withoutAccountHalf.body?.item));
-        expect(navIds(withAccountHalf.body?.item)).toHaveLength(32);
+        // 31: the composition the count in the test above states.
+        expect(navIds(withAccountHalf.body?.item)).toHaveLength(31);
 
         // The mechanism behind the invariance, asserted rather than assumed:
         // the bundle aims exactly one contribution at `setup` and one at