Support a configurable product/brand name (whitelabel) instead of hardcoded titles

[xuyushun441-sys]

Background

Downstream deployments (e.g. ObjectOS Cloud at https://cloud.objectos.ai) want to set a single product / brand name and have it surface consistently across auth emails, page titles, and API docs. Today the brand string is partly configurable, partly hardcoded — there is no single knob.

In the cloud repo we already wired OS_APP_NAME (default ObjectOS Cloud) into the auth plugin's appName, which covers email templates. The remaining surfaces are hardcoded inside the framework and cannot be overridden by deployers.

Hardcoded brand strings in the framework

1. Account / auth SPA <title> — apps/account/index.html:10

   <title>ObjectOS Account</title>

2. REST API docs <title> — packages/rest/src/rest-server.ts:1402

   <title>ObjectStack API Docs</title>

   (Note the inconsistency: "ObjectOS" vs "ObjectStack".)
3. Auth email appName default — packages/plugins/plugin-auth/src/auth-manager.ts:1105

   return this.config.appName ?? 'ObjectStack';

   This one is already overridable via AuthManagerConfig.appName (good) — listed only for completeness as the canonical source of the brand name.

Proposal

Introduce a single configurable product name (e.g. appName / productName) resolvable from one source — config field and/or OS_APP_NAME env — and thread it into:

• apps/account HTML title (inject at build/serve time, or render dynamically)
• REST docs title in rest-server.ts (add an option to RestServer, falling back to the current default)
• Keep auth-manager appName as the canonical default, but align its fallback with the same source so all three agree

Acceptance criteria

• Setting one value (config or OS_APP_NAME) renames auth emails, the account SPA title, and the API docs title together.
• Backward compatible: unset → current defaults (suggest unifying the default to a single string rather than today's mix of ObjectOS / ObjectStack).

Context

Filed from the cloud repo while wiring OS_APP_NAME → auth appName. The framework-side titles are the missing piece for a fully configurable product name.

[xuyushun441-sys]

Correction: the settings UI already exists — it's just not wired up

After more digging, the framework already has a UI-editable Branding settings page; there is no need to invent a new sys_settings object. The missing piece is purely consumer wiring.

What already exists

service-settings ships a Branding manifest — packages/services/service-settings/src/manifests/branding.manifest.ts:

• Namespace branding, scope: 'tenant', gated by setup.access / setup.write
• Field workspace_name (label "Workspace name", default ObjectStack, 1–60 chars) — plus support_email, theme_mode, accent_color, logo_url
• Editable in the UI at …/_console/apps/setup/system/settings/branding and persisted via the settings service

The actual gap

Nothing consumes branding.workspace_name. A repo-wide search finds zero runtime readers — the value is stored but never used. So today, changing "Workspace name" in the UI renames nothing.

• Auth email appName still resolves from config/env only — auth-manager.ts:1105 → this.config.appName ?? 'ObjectStack'
• HTML titles are still hardcoded (apps/account/index.html:10, packages/rest/src/rest-server.ts:1402)

Revised proposal

Wire the existing branding.workspace_name setting into the brand surfaces, with this resolution order:

branding.workspace_name (tenant setting, UI-editable)
  ?? OS_APP_NAME (env)
  ?? built-in default

• Auth email appName resolves from the branding setting (env as fallback). Needs runtime resolution at send-time + caching, since the setting is tenant-scoped and the value is currently read once at plugin construction.
• apps/account HTML title
• REST docs title (rest-server.ts)
• Align the default — manifest defaults to ObjectStack, auth defaults to ObjectStack, but apps/account/index.html says ObjectOS Account. Pick one canonical default.

Acceptance criteria

• Setting Workspace name in the Branding UI renames auth emails, the account SPA title, and the API docs title — no redeploy required.
• OS_APP_NAME still works as the boot-time fallback when the setting is unset.

(Context: in the cloud repo we wired OS_APP_NAME → auth appName (default ObjectOS Cloud) as the fallback layer. The UI-driven layer is this framework-side wiring.)

[xuyushun441-sys]

The core wiring — auth email {{appName}} ← branding.workspace_name — is up in #1450.

• Binds on kernel:ready + re-applies on settings:changed (mirrors EmailServicePlugin).
• Only an explicitly-set value overrides; manifest default falls through to the configured appName, so OS_APP_NAME still wins when the setting is untouched.
• 3 new tests, 21/21 passing.

Still open from this issue (left as a focused follow-up — separate layers):

• apps/account/index.html <title> (client-side document.title on boot)
• rest-server.ts /docs <title> (thread settings into RestServer)
• reconcile conflicting defaults (ObjectStack vs ObjectOS Account)