@@ -0,0 +1,11 @@
+---
+'@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 (a boot-time binding is skipped where the namespace it reads does not exist; no accept set or served shape moves)
+
+`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 that read failed on every such boot and logged `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 walled deployment nothing is read and nothing is logged, and the configured app name (`OS_APP_NAME` and its chain) stays in force. That is the name such a deployment always got, since the walled read only ever saw organization-less rows. On a single-organization deployment a saved name applies as before.
@@ -24,7 +24,7 @@ Setup → Branding saved values that nothing in the console ever read. Under the
 - 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.
 
-**BREAKING: under the `group` and `isolated` postures the Branding namespace is not offered.** It is absent from `GET /api/settings`, and `GET` or `PUT /api/settings/branding` is refused with `404 UNKNOWN_NAMESPACE`, the answer every unknown namespace gets. 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, through `OS_PRODUCT_NAME`, `OS_LOGO_URL` and `OS_BRAND_COLOR`. 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.
+**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, through `OS_PRODUCT_NAME`, `OS_LOGO_URL` and `OS_BRAND_COLOR`. 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.** 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 deployment's branding with the three `OS_*` variables.
 
 
@@ -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`, so it was listed on every deployment, including those whose settings service does not offer the `branding` namespace. Under the `group` and `isolated` tenancy postures that namespace is not offered, and the entry opened 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`.