Repository navigation
Setup → Branding saves, but the workspace name, accent colour and logo change nothing in the app #24766
Description
Filing gate ③ a task the maintainer set: objectstack-ai/hotcrm#2188, the maintainer's browser pass of 2026-10-20. Each defect gets its own card, by the maintainer's ruling 「按照按照具体的issue单独提交卡片，不受数量限制。」 (recorded on objectstack-ai/hotcrm#2188, 6283467378). This is finding F-16 of track 2 (Setup as the system administrator), by the cloud tester session_01VuXyJvhGKJy8qeUvhKyxzv. It was measured on HotCRM main f22dfa52 with @objectstack/* 18.0.0-next.5, in Chromium at 1440×900 on a locally booted, seeded install. The evidence is on the branch claude/qa-setup-pass-2026-10-20 at ed4f40e42, which is never merged. Filed by the repo:hotcrm seat 2 (os-support-ai, session session_01KqkTQNLcxVc588eZpJmp1r). ⛔ Not a claim. Grade: triage's.
Reader (who acts): objectstack triage routes it.
The finding, as measured
- Persona / URL: dev admin,
/apps/setup/system/settings/branding. - Steps: set Organization name "HotCRM QA Org", Accent colour
#e11d48, Logo URL/_console/favicon.ico; Save (200 "Settings saved"); reload; open the login page in a fresh browser. - Expected: the page's description, "Organization name, logo, and accent colour."
- Actual: login page still "ObjectOS"; document title "Setup — ObjectOS"; CSS
--primaryunchanged (215 19% 35%); no logo anywhere. Logo URL also acceptsnot a urland#e11d48(typeurlinput, no validation). - Evidence:
25-config-branding-after-save.png,25-config-branding-effect-login.png,25-config-branding-effect-app.png. - class: a. Reach: every deployment.
- Suspected landing: objectstack
service-settingsbranding namespace → console theme / login shell. - Dedupe words: branding not applied, accent colour no effect, logo url validation.
Seat review
- Landing (seat review): of the branding settings, only
workspace_namehas a reader (plugin-auth,auth-plugin.ts:1064). Nothing passes the rest to the runtime config the console reads.
Dedupe
Method: semantic search_issues on objectstack-ai/objectstack and objectstack-ai/objectui, open and closed, using the finding's own dedupe words and a second phrasing; plus a grep of every issue title (objectstack #1–#24751, objectui #7–#13153) listed through the repo-scoped issues?state=all endpoint, because the semantic search can miss title words (objectstack#14743).
- 2 hits in objectstack, 3 in objectui, none on point. New.
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 20, 2026
Claim: PM loop round 2 · 2026-10-20T12:14Z
Session:
session_01UmqzD97e14iws6hmVhgZ5yAccount:
os-support-ai(the seat's linked user asGET /useranswers it; always the card's assignee)Branch:
claude/issue-24766-branding-settings(a readings-only dispatch: no edit, no PR; the readings are posted to this card)Worktree: none (readings on
origin/mainfrom the shared checkout, read-only)Domain:
domain:servicesSeat:
domain:services#2(seat post #21118)File surface: none written. Read:
packages/services/service-settings/src/manifests/branding.manifest.tsand its writers and readers;plugin-auth'sbranding.workspace_namereader;packages/cloud-connection/src/runtime-config-plugin.ts(the product name and logo the console reads, with theirOS_*environment fallbacks); the spec'sAppBranding; the console's theme and login shell (objectui at the console pin); HotCRM's use of each (stop on breach; explain in the report)Container & model:
S,mode:subagent,model: opus(TIER_DEFAULT; a readings-only dispatch whose output is a decision analysis)Clause-②: no
Responsibility:
service-settings declares a branding namespace (organization name, accent colour, logo URL) whose accent colour and logo have no runtime reader | the console's runtime config (product name, logo, with environment fallbacks) and app-level AppBranding may already cover part of it, to be measured | every Setup admin on every deployment; measured on a HotCRM install 2026-10-20 (card)Thread-read: none
Serial constraints cleared: nothing is written. No in-flight claim in either services seat names
service-settings.The card asks to implement or retire a declared settings surface, which is a product decision. This dispatch measures both sides, the overlapping surfaces included, so that the decision analysis rests on readings.
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
os-dev-report
{
"issue": 24766,
"status": "reading",
"branch": "claude/issue-24766-branding-settings",
"pr": null,
"session": "session_01UmqzD97e14iws6hmVhgZ5y — mode:subagent, the dispatching seat's session id (shared)",
"premise_still_valid": true,
"summary": "Readings-only dispatch, no code. The card's premise holds and is wider than stated: the branding manifest declares five keys and only workspace_name has a reader, plugin-auth's product name for auth emails, the TOTP issuer and the MCP resource name, never the console; accent_color, logo_url, support_email and theme_mode have zero readers in objectstack and in objectui at the pin. Everything the QA pass saw comes from other, governed surfaces: the login wordmark and the title suffix are runtime-config productName (OS_PRODUCT_NAME, default 'ObjectOS'), Setup's --primary 215 19% 35% is the Setup app's own locked AppBranding.primaryColor #475569, and no logo shows because OS_LOGO_URL is unset; the per-organization name and logo already live on sys_organization. The logo_url sub-finding is a class: the server's validatePatch never judges specifier type and the console saves with no form element, so nothing validates url/email/color anywhere. Recommendation in open_questions: option B (retire the four zero-reader keys, keep workspace_name with an honest description), precedent #21970.",
"readings": {
"pins": "objectstack origin/main 6b9e6df (shared checkout, read with git show/grep only); objectui 616df6598b (.objectui-sha pin); HotCRM origin/main b94cf8568. All three checkouts are shallow: objectstack's two boundary commits (621a487, 2026-08-20; ac76425, 2026-09-07) already carry branding.manifest.ts, so whether accent_color or logo_url ever had a reader before that window is NOT MEASURED. Cloud repo: NOT MEASURED (GET repos/objectstack-ai/cloud answered 403; search/code answered 403 'sessions are bound to their configured repositories').",
"1_declared_surface": [
"packages/services/service-settings/src/manifests/branding.manifest.ts (origin/main 6b9e6df): namespace 'branding', version 1, description 'Organization name, logo, and accent colour.' (:11), scope 'tenant' (:12), readPermission 'setup.access' (:13), writePermission 'setup.write' (:14), category 'Workspace', order 5.",
"Five value keys, not three: workspace_name text, required, default 'ObjectStack', 1..60 chars (:19-20); support_email email, no default (:21-22); theme_mode select light/dark/system, default 'system' (:25-31); accent_color color, default '#6366f1' (:32); logo_url url, no default (:33-34).",
"Env spellings (settings-service.types.ts:430-433 envKeyOf): OS_BRANDING_WORKSPACE_NAME, OS_BRANDING_SUPPORT_EMAIL, OS_BRANDING_THEME_MODE, OS_BRANDING_ACCENT_COLOR, OS_BRANDING_LOGO_URL; each locks the key at the top of the cascade.",
"Declared beyond the manifest only as design intent, never as a consumer: ADR-0007 (Accepted) example 2 sketches a branding manifest (product_name, tagline, accent_color, logo_url, theme; docs/adr/0007-settings-manifest-and-kv-store.md:207-222) and its plan item 9 reads 'plugin-auth — BrandingSettingsManifest (logo / colours / product name)' (:400); the spec's SettingsClient doc names a consumer 'BrandingPlugin' (packages/spec/src/system/settings-client.zod.ts:6, generated into content/docs/references/system/settings-client.mdx:13) that does not exist anywhere in the tree; the service README lists branding as 'Owner plugin: (built-in fallback)' with 'Organization name, logo, accent colour' (packages/services/service-settings/README.md:110); plugin-security states the intent 'Tenant-scoped manifests (branding, feature_flags) keep using setup.access so org admins CAN configure their own org's branding' (packages/plugins/plugin-security/src/objects/default-permission-sets.ts:345-347). No content/docs page lists the keys. The translations (src/translations/en.ts:74-80, es-ES.ts:70-76, ja-JP.ts:70-76, zh-CN.ts:110-116) carry copy for all five."
],
"2_readers_today": [
"workspace_name — one reader. plugin-auth auth-plugin.ts:1090-1121 reads settings.get('branding','workspace_name', {}) at kernel:ready and on every branding change (subscribe, :1117), and passes ONLY an explicitly set value (source not 'default') to authManager.setAppName (auth-manager.ts:6466-6468). getAppName() = override, else config.appName (the OS_APP_NAME chain under objectstack serve), else 'ObjectStack' (auth-manager.ts:6475-6477). It renames: the appName placeholder of every built-in auth email (read per send), the TOTP otpauth issuer/label handed to better-auth (read once at instance build, auth-manager.ts:1772-1786), and the MCP OAuth protected-resource resource_name (auth-manager.ts:7266). It never reaches the console. The card's citation auth-plugin.ts:1064 has drifted to :1090-1121.",
"Why the login page still says 'ObjectOS': the console's product name is a different value from a different door. objectui AuthLayout BrandMark reads getProductName()/getLogoUrl() (apps/console/src/pages/auth/AuthLayout.tsx:80-110), which return runtime-config branding.productName or 'ObjectOS' and branding.logoUrl (packages/app-shell/src/runtime-config.ts:521-545); the server fills those from the RuntimeConfigPlugin constructor option, else OS_PRODUCT_NAME, else 'ObjectOS' (packages/cloud-connection/src/runtime-config-plugin.ts:727-729). The title 'Setup — ObjectOS' is ConsoleLayout's app label plus getProductName() (packages/app-shell/src/layout/ConsoleLayout.tsx:216).",
"Consequence for workspace_name under multi-organization postures: the auth reader passes an empty context, so its organization reach is 'unwalled' under single (it takes an organization's row, settings-service.ts:1658-1676) but 'organization-less' under group/isolated, where it reads only rows written with no organization; under the walled posture a tenant-scope write naming no organization is refused (pinned over HTTP in packages/qa/dogfood/test/settings-organization-isolation.dogfood.test.ts:178-193). So under group/isolated every value an org admin can save is invisible to the one reader. Read from code and the existing dogfood pin, not run in this dispatch.",
"accent_color, logo_url, support_email, theme_mode — zero readers. git grep over objectstack origin/main 6b9e6df non-test code finds each key only in branding.manifest.ts and the four translation bundles; objectui at the pin has no non-test reference to any of the five keys, nor to /api/settings/branding. The only other hits are test literals: theme_mode in settings-service.test.ts (28 lines, as a generic select/lock/env example), and logo_url as a raw sys_setting row-identity literal in packages/drivers/driver-sql/src/sql-driver-sys-setting-organization-unique.test.ts:319 (never through the manifest). The console's theme default is hard-coded: ThemeProvider defaultTheme='system' (objectui packages/app-shell/src/console/ConsoleShell.tsx:172)."
],
"3_overlapping_surfaces": [
"runtime-config (packages/cloud-connection/src/runtime-config-plugin.ts, lane domain:cli): serves GET /api/v1/runtime/config and the legacy /api/v1/studio/runtime-config (:1035-1037) with branding { productName, productShortName, stage?, logoUrl, faviconUrl, brandColor, pwaDescription, pwaThemeColor } (:995-1011). Each resolves host option, else env, once at construction (:727-762): OS_PRODUCT_NAME (default 'ObjectOS'), OS_PRODUCT_SHORT_NAME, OS_PRODUCT_STAGE, OS_LOGO_URL (:753/:758; option docs :605), OS_FAVICON_URL, OS_BRAND_COLOR, OS_PWA_DESCRIPTION, OS_PWA_THEME_COLOR (default brandColor or '#4f46e5'). objectstack serve constructs it with no branding option (packages/cli/src/commands/serve.ts:1921-1929, :3970, :4026), so under serve the env is the only input. Process-wide: the same for every organization, changed only by redeploy/restart. The door is classified anonymous with the reason 'the console's pre-sign-in branding and runtime posture, no tenant data' (packages/qa/dogfood/test/anonymous-door-sweep.classification.ts:285-289).",
"Console readers of runtime-config branding (objectui 616df6598b (.objectui-sha pin)): productName → document.title at boot (apps/console/src/main.tsx:117), auth brand mark (AuthLayout.tsx:81), home wordmark and product-home mark (packages/app-shell/src/layout/AppHeader.tsx:327-328, :845), loading screen (packages/app-shell/src/chrome/LoadingScreen.tsx:105-115), title suffix (ConsoleLayout.tsx:216), PWA manifest (main.tsx:131-145); logoUrl → auth brand tile, product-home mark, loading screen, device-auth page (DeviceAuthPage.tsx:34-35); faviconUrl → favicon (main.tsx:120-127, index.html:90-94); brandColor → ONLY the PWA theme colour via getPwaThemeColor (runtime-config.ts:540, :556), never --primary. All getters read a module value set at boot: non-reactive.",
"AppBranding (packages/spec/src/ui/app.zod.ts:1208-1222; strict; primaryColor, accentColor, logo, favicon): per APP, authored metadata. Readers at the pin: ConsoleLayout hands activeApp.branding to AppShell (ConsoleLayout.tsx:209-216), useAppShellBranding maps primaryColor to --primary, --ring, --sidebar-primary and accentColor to --accent (packages/layout/src/AppShell.tsx:147-201); AppMark draws branding.logo (liveness ledger packages/spec/liveness/app.json:59). Producers: objectui plugin-designer BrandingEditor / AppCreationWizard / EditAppPage (app.json:60), i.e. Studio, which needs manage_metadata/studio.access; an org admin is deliberately withheld both (default-permission-sets.ts:338-347). The Setup app pins its own colour, primaryColor '#475569' with protection lock 'full' (packages/platform-objects/src/apps/setup.app.ts:39-46). #475569 is exactly HSL 215 19% 35%, the --primary the QA pass read on Setup. The spec already names AppBranding 'the one colour/logo surface' (packages/cli/src/commands/explain.ts:226-232; stack.zod.ts:2017-2022 and the semantic migration 18.stack-themes-carrier-retired.ts, maintainer ruling 2026-08-21, which retired stack themes in favour of it).",
"A fourth home the dispatch did not list: sys_organization's better-auth columns name and logo (packages/platform-objects/src/identity/sys-organization.object.ts:298-323), changed through update_organization / rename_organization (:221-255, the latter requiresFeature multiOrgEnabled) and rendered by objectui's OrganizationsPage avatar and name (packages/app-shell/src/console/organizations/OrganizationsPage.tsx:250-256), the org settings page (manage/SettingsPage.tsx:70-72) and the WorkspaceSwitcher name (layout/WorkspaceSwitcher.tsx:101-129). This is the per-organization name and logo, governed and read; branding.workspace_name (label 'Organization name' since #24207) and branding.logo_url duplicate it without a reader.",
"Map — who owns what today, and who can change it at runtime: deployment product name in the console = runtime-config productName (env/host option, operator, restart; not tenant-editable); deployment product name in mail/TOTP/MCP = getAppName chain, with branding.workspace_name as the only runtime-editable rung (setup.write; effective only under the single posture); deployment logo/favicon = runtime-config logoUrl/faviconUrl (env, operator); UI colour --primary/--accent = per-app AppBranding (metadata, Studio, manage_metadata; Setup locked); per-app logo/favicon = AppBranding.logo/favicon; organization name/logo = sys_organization (org owner/admin via better-auth); theme mode = hard-coded 'system' plus the user's own toggle. Nothing a tenant admin can change at runtime alters the console's name, logo or colour."
],
"4_real_pull": [
"HotCRM (origin/main b94cf8568): sets AppBranding on its CRM app (src/sales/apps/crm.app.ts:129-133: primaryColor '#EA580C', logo and favicon the inlined HOTCRM_ICON). Zero hits for any branding settings key, /api/settings/branding, OS_PRODUCT_NAME, OS_LOGO_URL, OS_BRAND_COLOR, OS_FAVICON_URL, OS_APP_NAME or OS_BRANDING_.",
"objectstack examples: AppBranding in examples/app-crm/src/apps/crm.app.ts:9, examples/app-showcase/src/ui/apps/index.ts:25, examples/app-todo/src/apps/todo.app.ts:9; zero settings-branding keys and zero OS_ branding variables (app-showcase constructs RuntimeConfigPlugin with no branding option, objectstack.config.ts:164).",
"Cloud: NOT MEASURED here; the in-tree reading in runtime-config-plugin.ts:57-59 records 'control: OS_PRODUCT_NAME, cloud repo 9 hits', i.e. the hosted distribution brands through runtime-config.",
"Tests and QA: no test, dogfood harness or checklist item asserts that a branding setting APPLIES. workspace_name is the generic tenant-scope fixture key of five dogfood suites (settings-config-change-audit, settings-audit-global-rung-sibling, settings-organization-isolation, audit-log-parent-read-gate, plus the upgrade harness) and of config-change-audit.test.ts; they assert storage, audit and isolation, not effect. The upgrade harness writes only workspace_name (packages/qa/dogfood/test/upgrade-harness/populate-fixture.ts:146) and reads nothing branding-specific back; fixture-18.0/database.sql holds only workspace_name rows (:657 sys_setting, :661 sys_setting_audit). The platform checklist lists branding only as a GET round-trip variant (docs/qa/platform-checklist/areas/platform-core.json:742-761) and explicitly calls a saved form without an observable consumer a FALSE PASS; the runtime-config boot item checks the payload shape (:2104).",
"Producers of the keys: none outside tests. HotCRM's QA pass on 2026-10-20 (hotcrm#2188 F-16) is the only recorded human write."
],
"5_logo_url_validation": [
"Server side: every PUT /api/settings/:ns runs SettingsService.validatePatch (called at settings-service.ts:2055; body :2326 onward). It judges required, the option table, pattern, valueDomain and the bounds family (min/max/minLength/maxLength/step). No branch judges the specifier TYPE: there is no URL, email, phone or hex-colour check anywhere in service-settings (git grep for the type literals finds only manifest declarations). The env door (effectiveEnvOverride, :1115-1214) applies the same families, so OS_BRANDING_LOGO_URL is unchecked too.",
"Client side (objectui 616df6598b (.objectui-sha pin)): SettingsField renders url/email as an input of type url/email (apps/console/src/pages/settings/SettingsField.tsx:435-449) and color as a picker plus a free-text input (:619-637), but SettingsView saves from a button click (SettingsView.tsx:209-216, :422) with no form element, so the browser's constraint validation never runs. No layer validates.",
"Declared contract it breaks: ADR-0007's specifier table, 'email / url / phone — typed input — string — format validation' and 'color — colour picker — hex string' (docs/adr/0007-settings-manifest-and-kv-store.md:115, :122). The family spans six shipped keys: branding.support_email, branding.logo_url, branding.accent_color, company.website, company.primary_contact_email, and mail.from_email (required, live reader). Reported below as an out-of-scope finding; option B removes the branding instances but not the class."
],
"6_multi_tenant": [
"The login page has no session, so no organization. runtime-config's answers depend on (a) construction-time options and env (branding, cloudUrl, upgradeUrl, telemetry, base features), (b) the request's Host header resolved through the env-registry service when one is mounted (defaultOrgId, defaultEnvironmentId, singleEnvironment, plan features; runtime-config-plugin.ts:925-965; 'not mounted (file/CLI mode)', :907-908), and (c) the observed route table (installLocal, marketplace). Branding depends only on (a).",
"So a per-organization name or logo on the login page is meaningful only where the hostname identifies the organization (the hosted per-subdomain environment). On a self-hosted single-host multi-organization deployment there is no organization before sign-in, and on the default single posture the one organization is the deployment, which the OS_* variables already brand. Serving tenant rows on that door would turn an anonymous 'no tenant data' door into one that discloses a tenant's settings by hostname.",
"After sign-in the console still could not read branding for an ordinary member: the namespace's readPermission is setup.access, which members do not hold. An option that feeds the console needs a new read door or a fold into runtime-config either way."
]
},
"tests": "None run, by dispatch: readings-only (no worktree, no build closure, no tests, no PR). Every reading is git show / git grep at objectstack origin/main 6b9e6df, objectui 616df6598b (.objectui-sha pin) and HotCRM origin/main b94cf8568; the HSL of #475569 was computed by hand (71/85/105 → 215 19% 35%). No ablation: no tested behaviour changed.",
"gates": "None: no diff, so no derived gate family and no CI check-runs. NOT MEASURED: every family, reason: readings-only dispatch with no branch push.",
"mcp_calls": "0 — no MCP GitHub tool called",
"api_writes": "1 — POST /repos//issues/24766/comments (this os-dev-report, via scripts/pm/post-stamped.mjs on the fleet relay). Reads only otherwise: REST GET issues/24766, issues/24766/comments, issues/24142/comments (a prior report's shape); GET repos/objectstack-ai/cloud (403); six GET search/code (403).",
"open_questions": [
{
"question": "Which option for the branding settings namespace, whose page promises 'Organization name, logo, and accent colour' while only workspace_name (as the auth email/TOTP/MCP product name) has a reader?",
"options": [
"A — Implement (feed branding.* to the console). Changes: a door that serves tenant branding before sign-in (runtime-config reading the settings service per request, organization from the hostname resolver or the single posture's one organization), a precedence between the settings layer's OS_BRANDING_* and runtime-config's OS_PRODUCT_NAME/OS_LOGO_URL/OS_BRAND_COLOR (two env spellings for one value), a new rule for workspace colour versus per-app AppBranding (Setup's locked #475569, HotCRM's #EA580C), objectui wiring (runtime-config.ts getters, AuthLayout BrandMark, AppHeader, ConsoleLayout title, AppShell theme tokens, ConsoleShell defaultTheme, made reactive), plus type validation for url/color. Blast radius: the anonymous door's classification ('no tenant data') changes, which is a security-boundary relaxation (services lane human floor) and Clause-② yes (public surface widened); a third organization name beside sys_organization.name. Files and owners: packages/cloud-connection (domain:cli), service-settings and plugin-auth (domain:services), dogfood anonymous-door classification (domain:cli), content/docs (domain:devx), objectui app-shell/console/layout (domain:ui; no carrier card named, the seat files one). Effort: no precedent; L, two repos, three lanes, maintainer review on the door.",
"B — Retire what has no reader. Changes: drop accent_color and logo_url, and by the same measurement support_email and theme_mode, with the Appearance group; keep workspace_name; bump version 1→2 (the spec's 'Increment when keys are renamed/removed'); rewrite the description to the measured effect (the product name in sign-in emails, the authenticator label and the MCP sign-in; effective on a single-organization deployment); point the admin to AppBranding (app colour/logo), OS_PRODUCT_NAME/OS_LOGO_URL (deployment name/logo) and the organization settings (organization name/logo). Blast radius, measured by the #21970 precedent's own readings: stored rows are kept, never deleted, ignored on GET, refused by name on PUT (400 UNKNOWN_KEY), never block a live-key save, and come back on a rollback; OS_BRANDING_ACCENT_COLOR and siblings stop being read. Upgrade harness: unaffected (writes and stores only workspace_name). Tests: settings-service.test.ts's 28 theme_mode lines re-point to another domain-less select, as #21970 did; the translation coverage test (from #21970) forces the four bundles to drop the copy. objectui: no code change (manifest-driven renderer). Cloud control plane mounts the same manifests (per #24207): NOT MEASURED whether it writes the keys. Files and owner: service-settings manifest, four translation bundles, README.md:110, tests, changeset (minor, BREAKING banner, Clause-② no (narrowing), ADR-0087 not-required: settings values, not metadata) — all domain:services, one package. Effort: precedent #21970 (0d8ea5e): 10 files, +210 −106; S–M.",
"C — Fold into the governing surface. C1: runtime-config reads branding.* with OS_* as fallback, retiring one env spelling; it unifies the two product-name chains (console 'ObjectOS' via OS_PRODUCT_NAME, mail 'ObjectStack' via OS_APP_NAME) but carries all of A's server-side cost (anonymous door now carries tenant data, organization resolution before sign-in, Clause-② yes, security floor) and still needs the AppBranding colour precedence; L, domain:cli plus domain:services plus small objectui changes. C2 (reverse): retire the whole namespace and leave the mail name to OS_APP_NAME; this removes workspace_name, the one key with a working reader and the only runtime rename an admin has, so it retires a live capability; S, domain:services. Neither beats B on the measured pull.",
"D — Text only: correct the description (manifest plus four bundles, about 5 lines, domain:services). Inadequate under declared ⇒ enforced: accent_color, logo_url, support_email and theme_mode stay on the page and in PUT's accept set, so an admin or an AI keeps writing values the runtime never honours, with a 200."
],
"recommendation": "B(并把实测同为零读者的 support_email、theme_mode 一并退役;保留 workspace_name,描述改写为它实际生效的范围)。四轴:① 实际业务需求 —— 实测写者只有测试;HotCRM 与三个示例全部走 AppBranding(crm.app.ts:129-133);云端品牌走 runtime-config(树内读数 OS_PRODUCT_NAME 9 处);没有任何测试、dogfood 或清单断言品牌设置生效;唯一的人工写入就是本卡的 QA。A/C1 服务的是投机性的「租户运行时白标」场景,零具名拉动。② 项目长远合理性 —— 身份已有三个各自有读者、有治理的家:部署级 = runtime-config(env/宿主选项),应用级 = AppBranding(spec 自称唯一颜色/Logo 面,2026-08-21 维护者裁决退役 stack themes 时同形确认),组织级 = sys_organization.name/logo(better-auth 列,控制台组织页与切换器在读)。branding.* 是第四个无读者的重复家;B 去掉重复,符合 contract-first。A/C1 要把匿名「无租户数据」门变成按主机名暴露租户设置的门,并新造「工作区色 vs 应用色」优先级与第三个组织名,长期代价大于收益。③ 防 AI 写错 —— B 之后对已退役键的 PUT 响亮拒收(400 UNKNOWN_KEY,按名点出),符合契约收紧优于消费端宽容;D 保留一个 200 却无效果的陷阱,正是「声明一个运行时不兑现的能力」;A 修好了这四个键,却引入更多可写错的面(两套 env 拼写、两层颜色优先级)。④ 创业阶段不扩散 —— A/C1 是跨两仓三车道的新能力面加安全地板复核;B 立即退休、无分阶段窗口、无双拼写宽限、不加新门禁,先例 #21970 已证实单包 S–M 可落地。权衡如实呈现:B 之后租户管理员在运行时没有任何可改变控制台名称/Logo/颜色的手段(今天其实也没有,只是页面在声称有);若维护者认定这是产品需求,应作为新卡按 A 立项并先裁登录前组织解析与匿名门的取舍,而不是保留无读者的键。B 的残余(同卡内,交维护者一并定夺):workspace_name 的唯一读者以空上下文读取,在 group/isolated 姿态下组织管理员保存的值无人读;B 内的最小诚实处置是描述写明「单组织部署生效」,把它迁成平台级键或让认证邮件按组织取名属于新能力,不荐在本卡做。"
}
],
"out_of_scope_findings": [
"class: b · reach: public door — Setup → Branding Save, i.e. PUT /api/settings/branding, accepted logo_url 'not a url' and '#e11d48' with 200 'Settings saved' (measured by this card's QA pass on HotCRM, hotcrm#2188 F-16, 2026-10-20); the same validatePatch serves every namespace · evidence: ADR-0007 declares 'email / url / phone — format validation' and 'color — hex string' (docs/adr/0007-settings-manifest-and-kv-store.md:115, :122); SettingsService.validatePatch (settings-service.ts:2326 onward) and effectiveEnvOverride (:1115-1214) judge no type family; the console saves with no form element (SettingsView.tsx:209-216). Six shipped keys: branding.support_email, branding.logo_url, branding.accent_color, company.website, company.primary_contact_email, mail.from_email (required, live reader). Seat files it standalone (option B removes the branding instances, not the class); lane domain:services. Seam: spec:SpecifierType url/email/phone/color (ADR-0007 specifier table) → runtime:SettingsService.validatePatch | renderer:objectui SettingsField · dedupe words: settings url validation, specifier type format validation, settings email not validated, color hex not validated",
"class: b · reach: public door — the login page reads 'ObjectOS' on an unconfigured install (this card's QA measurement) while the operator docs declare the default 'ObjectStack' · evidence: content/docs/deployment/environment-variables.mdx:136 declares OS_PRODUCT_NAME 'default ObjectStack, shown in the UI chrome and emails' and :137 OS_PRODUCT_SHORT_NAME default 'OS'; runtime-config-plugin.ts:727-730 defaults to 'ObjectOS' and to productName, and no email reads OS_PRODUCT_NAME (mail and auth name the deployment through the OS_APP_NAME chain, default 'ObjectStack', auth-manager.ts:6475-6477), so one deployment ships two product names; OS_LOGO_URL, OS_FAVICON_URL, OS_BRAND_COLOR, OS_PWA_DESCRIPTION, OS_PWA_THEME_COLOR and OS_PRODUCT_STAGE are read (:736, :753-757) but absent from that page. Falls inside #24766's follow-through under options B, C and D (the page points the admin at these variables), so the seat names it a sub-issue of #24766; lane domain:devx. Seam: spec:none (operator contract content/docs/deployment/environment-variables.mdx Branding table) → runtime:cloud-connection RuntimeConfigPlugin constructor | renderer:objectui AuthLayout BrandMark · dedupe words: OS_PRODUCT_NAME default ObjectOS, environment variables branding table, OS_LOGO_URL undocumented, product name two defaults",
"carrier: 承接者:无 · noted, not filed — packages/spec/src/system/settings-client.zod.ts:6 (and its generated page content/docs/references/system/settings-client.mdx:13) names 'BrandingPlugin' as a settings consumer; no such plugin exists in objectstack origin/main 6b9e6df. A doc comment only (class none: observation). If option B lands, its PR may drop the name in passing only if it already touches that file; it does not today (packages/spec is the spec lane's)."
],
"deviations": [
"The card cites auth-plugin.ts:1064 for the workspace_name reader; on origin/main 6b9e6df it is :1090-1121 (the dispatch's ~1091-1111 is right).",
"The dispatch names three keys; the measurement covers all five, and support_email and theme_mode are zero-reader too, so option B is analysed over four keys. Recorded, not chosen: the maintainer decides the set.",
"sys_organization's name/logo is a fourth overlapping surface the dispatch did not list; included in the map because it is the governed per-organization home.",
"Cloud repo reads NOT MEASURED (403 on every channel this container has)."
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
[Decision] Setup → 品牌(Branding)设置:实现「租户运行时白标」,还是退役没有读者的键?
domain:servicesseat 2 (seat post #21118) ·os-support-ai·session_01UmqzD97e14iws6hmVhgZ5y· 2026-10-20T12:34Z。依据:本卡只读读数报告(os-dev-report,origin/main6b9e6df909,objectui pin616df6598,hotcrmb94cf856);席位复核读数在同一 origin/main。Release:
session_01UmqzD97e14iws6hmVhgZ5y· 因:只读读数已交付,余下是「实现还是退役」的产品决定 · 去向:needs-user-decision,本笔清 assignee。一句话问题: Setup 的「品牌」页承诺「组织名称、Logo 和主题色」,管理员保存后控制台什么都不变。5 个键里只有「组织名称」有读者,而且它只改认证邮件、验证器 App 和 MCP 登录里的产品名,从不到达控制台。
背景(实测)
workspace_name、support_email、theme_mode、accent_color、logo_url(branding.manifest.ts:19-34)。workspace_name只有一个读者:plugin-auth用它作认证邮件、TOTP 发行方和 MCP 资源名里的产品名(auth-plugin.ts:1090-1121)。而且它用空上下文读取,在group/isolated姿态下组织管理员存的值没人读,只在单组织部署生效。其余 4 个键在 objectstack 与 objectui 中零读者(席位git grep复核:只命中 manifest 和四个翻译包)。productName(OS_PRODUCT_NAME,默认ObjectOS,runtime-config-plugin.ts:729);AppBranding.primaryColor#475569(setup.app.ts:44-46);OS_LOGO_URL。AppBranding(元数据;spec 称其为「唯一在用的颜色面」);sys_organization的name/logo(控制台组织页与切换器在读)。branding.*是第四个家,没有读者。AppBranding品牌化;0 处写品牌设置键;没有任何测试、dogfood 或检查清单断言品牌设置生效。唯一的人工写入就是本卡来源的 QA。云端品牌走 runtime-config(云端仓本容器不可读,未实测)。Governing text
stack.zod.ts:2017-2022:themes因「声明了但屏幕上什么都不变」退役(ADR-0049,维护者 2026-08-21 裁决 B),处方为「颜色请设app.branding.primaryColor/accentColor——唯一在用的颜色面」。6010771237)退役了零读者的本地化格式键。其理由(格式跟随用户语言)是该分支特有的,所以本卡不直接继承,只借用它的执行形状。是否改协议: B 不改 spec;设置值不是元数据,ADR-0087 判 not-required。A/C1 会扩大公开面(
Clause-②: yes),并把匿名的 runtime-config 门(分类理由「无租户数据」)变成按主机名下发租户设置的门。这是安全边界放宽,属人工地板。前提(复核命令)
for k in accent_color logo_url support_email theme_mode; do git grep -l "$k" origin/main -- packages ':!**/*.test.ts' ':!**/CHANGELOG.md' ':!packages/qa/**'; done(每个只应命中branding.manifest.ts与src/translations/下四个文件)。git show origin/main:packages/cloud-connection/src/runtime-config-plugin.ts | grep -n "'ObjectOS'"(应命中productName一行)。选项
accent_color、logo_url、support_email、theme_mode及「外观」分组,manifest 版本 1→2;保留workspace_name,描述改写为实际生效范围(认证邮件、验证器、MCP 登录;单组织部署);说明里指向三个真正的家400 UNKNOWN_KEY);已存的行保留,不删、读时忽略、回滚即回来branding.*,环境变量作回落workspace_name一起删业务含义直译: A =「做一个租户可自助的白标中心」;B =「把从没接电的三个开关拆掉,能用的那个写清楚只管哪里」;C1 =「换条路做 A」;C2 =「连能用的那个也拆」;D =「在没接电的开关旁贴张纸条」。
推荐:B
AppBranding,组织名称与 Logo 走sys_organization;没有第四个「保存了却不生效」的面。参照themes墓碑把颜色指向AppBranding,以及 fix(service-settings)!: retire date_format, time_format, number_format and first_day_of_week from the Localization manifest (#21958) #21970 的退役形状。workspace_name在group/isolated下组织管理员存的值没人读。B 内的最小诚实处置是描述写明「单组织部署生效」;把它改成平台级键、或让认证邮件按组织取名,属于新能力,不荐在本卡做。os-decision-facets
AppBranding;云端品牌走 runtime-config(树内读数)。400 UNKNOWN_KEY,不再「200 却无效」;D 留下陷阱,A 增加可写错的面。Prior rulings read: branding,accent_color,logo_url,workspace_name,appbranding → 0 hits; none; thread: none; repo: objectstack-ai/objectstack
(Cross-checked by
git grep -l -iE "accent_color|logo_url|workspace_name|branding\.manifest|AppBranding" origin/main -- AGENTS.md docs/adr: 1 file, ADR-0007, which sketches the manifest as design intent and names no reader. The 2026-08-21themesruling is quoted above from its spec tombstone and its semantic migration entry.)裁后执行
pm:queue,席位派发一个 services PR:manifest 改形、版本 1→2、四个翻译包、README、测试(按 fix(service-settings)!: retire date_format, time_format, number_format and first_day_of_week from the Localization manifest (#21958) #21970 的形状)、changeset(minor,BREAKING 横幅,Clause-②: no,收窄)。PR 合并即关本卡。pm:on-hold,另立功能父卡(spec、cli、services、objectui 分层子卡),先把「登录前组织解析」与「匿名门放宽」作为前置决策交你。mail.from_email等 6 个键,B 只能去掉其中 3 个。environment-variables.mdx:136把OS_PRODUCT_NAME的默认值写成ObjectStack并称它用于邮件,与代码不符(代码默认ObjectOS,邮件走OS_APP_NAME);OS_LOGO_URL等 6 个变量未列出。已立 docs(deployment): the environment-variables page gives OS_PRODUCT_NAME a default the runtime does not use and omits six branding variables the runtime reads #24887(席位,下一次唤醒)。Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
Maintainer ruling: B (「决策箱 三张同意」, the triage seat's chat, on triage's table that listed #24766 → B: retire the four reader-less keys, and keep
workspace_namewith an honest scope). Triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-20T14:36Zneeds-user-decision→pm:queue. The services seat dispatches the one PR from this card's 裁后执行 for B (6290956974):minorchangeset with the BREAKING banner,Clause-②: no, narrowing.workspace_name's description states where it actually takes effect: auth mail, the authenticator issuer and MCP sign-in, on a single-organization deployment.6292005854): the manifest version step is the conversion that carries the retired keys' stored values, so B goes into 18.x. The seat confirms in the PR that a save naming a retired key gets the loud refusal through that step. If it does not, 18.x warns, and the refusal is filed for 19.0.Generated by Claude Code
6 remaining items
objectstack-fleet commentedon Oct 20, 2026
Amendment to B′, from the maintainer: 「多租户下，就不应该显示品牌页」. Triage seat ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-20T14:55ZThis replaces B′'s
group/isolatedline, which had the page state that the platform operator sets these values:group/isolated, the Branding page is not offered at all: no Setup entry and no settings form. The server is the source, so it does not serve thebrandingnamespace under a walled posture, and the console shows only what it is served. Mechanism: the dev's choice.branding.*under a walled posture is refused loudly, never a silent 200. Deployment branding there is the platform operator's, through theOS_*env vars.single, nothing changes from B′: the page shows, and its three wired keys drive runtime-config.group, the namespace is absent from the settings listing and aPUTto it is refused. Undersingle, it is present.The state is unchanged:
pm:queue,domain:services, withcloud-connectiondeclared cross-lane.Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
Claim: PM loop round 3 · 2026-10-20T17:25Z
Session:
session_01UmqzD97e14iws6hmVhgZ5yAccount:
os-support-ai(the seat's linked user asGET /useranswers it; always the card's assignee)Branch:
claude/issue-24766-branding-runtime-configWorktree:
objectstack-issue-24766Domain:
domain:servicesSeat:
domain:services#2(seat post #21118)File surface:
packages/services/service-settings/src/manifests/branding.manifest.ts(theme_modeandsupport_emailretire, version 1 → 2, in fix(service-settings)!: retire date_format, time_format, number_format and first_day_of_week from the Localization manifest (#21958) #21970's shape; the descriptions state what applies);brandingentries,packages/services/service-settings/README.md;packages/services/service-settings/src/settings-service-plugin.ts, only for not offering thebrandingnamespace under a walled posture;packages/cloud-connection/src/runtime-config-plugin.ts(domain:cli; undersingle,productName/logoUrl/brandColorreadbranding.workspace_name/logo_url/accent_color, with theOS_*env vars as the fallback);.changeset/24766-*.mdper published package.packages/platform-objects/src/apps/setup-nav.contributions.ts(the onenav_settings_brandingline,domain:engine) andpackages/cli/scripts/check-app-nav-i18n.mjs(its contributor roster entry,domain:cli); in-lanepackages/plugins/plugin-auth/src/auth-plugin.ts(theapplyBrandbinding only).⛔ Not
service-settings/src/settings-service.ts(declared by epic #15194, C8: if the mechanism needs it, stop and report so the seat comments on #15194 first). ⛔ Notpackages/spec/**. ⛔ No objectui change. Stop on breach and explain in the report.Container & model:
M,mode:subagent,model: opus(TIER_DEFAULT;dispatch-gates --tieron this surface: no path-derived mandate, floor sonnet, default opus, ceiling fable)Clause-②: no (expected: the served
brandingblock keeps its shape, and the settings accept set narrows; the dev measures it and stops and reports if a published surface widens). The narrowing owes the seat's contract-review-tier review before the queue.Responsibility:
service-settings declares branding keys the runtime never reads | runtime-config already serves productName / logoUrl / brandColor that the console renders (AuthLayout) | every Setup admin; measured on a HotCRM install 2026-10-20 (card)Thread-read: 6293825075
Serial constraints cleared: no open PR touches
service-settings/srcorruntime-config-plugin.ts(all open PRs' files read this act). Seat 1's #24844 (auth.manifest.ts) has closed. #24882 (settings format checks) is queued, not dispatched.Under the maintainer's ruling B′ (
6293793948) and its amendment (6293825075), and the standing rule 甲 (#60156292005854): the manifest step carries the retirement, so all of it is 18.x.Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
os-dev-report
{
"issue": 24766,
"status": "blocked",
"branch": "claude/issue-24766-branding-runtime-config",
"pr": "#24959",
"session": "session_01UmqzD97e14iws6hmVhgZ5y — mode:subagent, the dispatching seat's session id (shared)",
"premise_still_valid": true,
"summary": "Ruling B′ plus its amendment, delivered except the 'no Setup entry' half, which lies outside the claimed file surface (stopped on breach, see open_questions). Under single, RuntimeConfigPlugin reads branding.workspace_name / logo_url / accent_color on every request into productName / logoUrl / brandColor. A key nobody set (source 'default') falls back to the host option, then OS_PRODUCT_NAME / OS_LOGO_URL / OS_BRAND_COLOR, and the derived productShortName / pwaDescription / pwaThemeColor follow what is served. theme_mode and support_email retire: manifest v1 to v2 in #21970's shape, four bundles, README, accent_color's unused #6366f1 default dropped. A save naming either is refused 400 UNKNOWN_KEY by name through the version step, so the 「甲」 fallback is not needed. Under group / isolated, SettingsServicePlugin holds the branding manifest back at init() and does not register it at kernel:ready once the posture in force is walled. It is then absent from GET /api/settings, GET and PUT /api/settings/branding answer 404 UNKNOWN_NAMESPACE, and the runtime-config door, which reads the namespace only when the settings service lists it, serves only the OS_* branding. settings-service.ts, packages/spec and objectui are untouched. The PR first line is 'Part of #24766' because the Setup nav entry (platform-objects) still shows under walled postures and now opens a page the server refuses 404.",
"tests": "At head 0c71c41 (after merging origin/main 644e4b2), with the dependency closures built first via turbo (34 tasks, exit 0):\n- service-settings vitest: 56 files, 924 tests passed (VERDICT command-exit 0). cloud-connection vitest: 53 files, 625 passed (VERDICT command-exit 0).\n- typecheck for both: exit 0. --listFiles shows the new and edited test files are compiled.\n- plugin-auth importer spot-check (auth-settings-ordering.pin, auth-settings-seeded-boot.pin, dev-admin-seed-workspace-timezone): 3 files, 12 tests passed.\n- New pins: settings-branding-posture.pin.test.ts (10, real plugin and ObjectKernel), 3 retired-key route pins in settings-routes.test.ts, branding.manifest.test.ts (5), runtime-config-branding-settings.test.ts (11).\nAblations, each via scripts/ablation-replace.mjs WRAP with blob-proven restore ('blob == HEAD and git diff HEAD is empty'); subjects resolve by relative import to src, so no dist rebuild was involved:\n1. Posture gate removed: 6 red ('expected [...] to not include branding', 'expected 200 to be 404').\n2. Door ignores the listing: 1 red ('expected { productName: Tenant Org ... } to match ... Env Product').\n3. source 'default' served as set: 3 red ('expected ObjectStack to be Env Product').\n4. theme_mode put back into the manifest: 7 red ('expected SETTINGS_VALIDATION to be UNKNOWN_KEY', the manifest pins, zh-CN / ja-JP / es-ES coverage).\n5. Read memoized at the first request: 1 red ('expected Env Product to be Renamed').",
"gates": "Local: dispatch-gates --commands --repo objectstack-ai/objectstack at 0c71c41 derived 68 commands, each run with its exit code captured before any pipe.\n- 67 exited 0.\n- pnpm check:dual-build-cjs-loads exited 3, PREREQUISITE NOT MET (packages outside the closure have no dist/): NOT MEASURED, and CI's full build runs it.\n- --ran with the exit codes recorded: '68 derived famil(ies) accounted for — 67 run, 1 NOT-MEASURED (1 DERIVED from a recorded exit 3)'.\nExtra, run because this diff moves lifecycle seams:\n- check:startup-registry-verdict exit 0;\n- check:settings-bind-window exit 0 ('4 declared / 0 self / 1 structurally upstream / 0 ledgered');\n- check:init-service-contract exit 0.\nAlso: ESLint --no-inline-config over the 12 touched .ts files exit 0; a control-byte scan of the 15 touched files found nothing. check:test-typecheck: not wired in either touched package (neither package.json declares it); their typecheck covers the tests.\nCI: on PR #24959 at report time the head's check-runs read 37 total: 4 success, 7 skipped, 18 in_progress, 8 queued. Build Core queued and Governed Surface Queue Guard in_progress. in_progress is the honest value; the report does not wait on CI.",
"line_budget": "1203 changed lines (+1070 / -133, 15 files) against the 3000-line human-merge threshold: under. No governed surface; no skills/** ledger touched.",
"files_changed": [
".changeset/24766-branding-settings-v2.md",
".changeset/24766-runtime-config-branding-settings.md",
"packages/cloud-connection/src/runtime-config-plugin.ts",
"packages/cloud-connection/src/runtime-config-branding-settings.test.ts",
"packages/services/service-settings/README.md",
"packages/services/service-settings/src/manifests/branding.manifest.ts",
"packages/services/service-settings/src/manifests/branding.manifest.test.ts",
"packages/services/service-settings/src/settings-service-plugin.ts",
"packages/services/service-settings/src/settings-branding-posture.pin.test.ts",
"packages/services/service-settings/src/settings-routes.test.ts",
"packages/services/service-settings/src/settings-service.test.ts",
"packages/services/service-settings/src/translations/en.ts",
"packages/services/service-settings/src/translations/es-ES.ts",
"packages/services/service-settings/src/translations/ja-JP.ts",
"packages/services/service-settings/src/translations/zh-CN.ts"
],
"mcp_calls": "0 — no MCP GitHub tool called",
"api_writes": "2 relay strokes, each a POST /repos/objectstack-ai/objectstack/dispatches through scripts/pm. (1) pr_create via fleet-write/dispatch.mjs, run 39476815766 success: the relay sent POST /repos/objectstack-ai/objectstack/pulls (draft) and POST /repos//issues/24959/assignees ['os-support-ai']; read back 14755 bytes sent, 14755 stored, identical. (2) This os-dev-report comment, POST /repos//issues/24766/comments via post-stamped.mjs. git push is not a REST write. Reads: REST GET issues/24766, its comments, pulls/24959 and the head's check-runs.",
"open_questions": [
{
"question": "The amendment's 'no Setup entry' half needs files outside the claimed surface. nav_settings_branding is a static item in packages/platform-objects/src/apps/setup-nav.contributions.ts (domain:engine), and no existing nav gate expresses 'hide unless this settings namespace is served'. Under group / isolated the entry still shows and now opens a page the server refuses 404 UNKNOWN_NAMESPACE. How should it land?",
"options": [
"A: Extend this claim; patch round on the same branch and PR #24959. The entry moves with the capability, the @objectstack/mcp connect-ui pattern (cloud ADR-0009, 'the nav lives and dies with the capability'). SettingsServicePlugin registers a one-item navigationContributions bundle through the manifest service from the kernel:ready step that already offers the namespace. SETUP_NAV_CONTRIBUTIONS drops the line. Files: platform-objects/src/apps/setup-nav.contributions.ts (one line, domain:engine) and packages/cli/scripts/check-app-nav-i18n.mjs (its contributor roster, so the moved id stays in that gate's population; domain:cli). Labels stay keyed apps.setup.navigation.nav_settings_branding. Then the seat changes the PR's first line to Fixes. Effort: S.",
"B: A separate card in domain:engine, Blocked-by #24959, doing the same move. #24959 keeps 'Part of' and must not land alone, since walled deployments would gain a dead Setup link between the two landings. Effort: S, plus serial cost.",
"C: A requiresService gate keyed on a service the settings plugin registers only under single. Rejected here: a service invented only to gate a nav entry is a mechanism made for its own observation (the runtime-config header rejects that shape by name), and it still edits platform-objects."
],
"recommendation": "A, because it is one landing (no window with a dead link), the precedent pattern already exists in-tree (mcp connect-ui), and the extra surface is one line in platform-objects plus one roster entry."
},
{
"question": "plugin-auth reads branding.workspace_name at kernel:ready and on change. With the namespace withheld under group / isolated, that read throws UnknownNamespaceError into its existing catch, which logs warn 'Auth: failed to apply branding.workspace_name: ...' once per walled boot. Read from code (auth-plugin.ts applyBrand, settings-service.ts get), not run. The effective app name is unchanged: under a wall that read only ever saw organization-less rows. plugin-auth is outside the claimed surface. Fix it here?",
"options": [
"A: Extend the same patch round to plugin-auth/src/auth-plugin.ts. Skip the binding when the settings service does not list the branding namespace, as the runtime-config door does, so a walled boot says nothing or one info line.",
"B: Leave the warn line. It is noise on every walled boot, and the effective name is correct."
],
"recommendation": "A, because a warn that fires on every correct walled boot trains operators to skim warn, which is the over-application the degradation-log-level rule warns against, and it is a few lines in the same lane (domain:services)."
},
{
"question": "The dispatch asked for 'Fixes #24766' as the PR's first line. The PR carries 'Part of #24766', because a merge would close the card with the Setup-entry half undone (os-dev rule: use Part of when the merge must not close the card). Confirm the seat edits the first line to 'Fixes #24766' once that half lands.",
"options": [
"A: Seat edits the first line after the patch round.",
"B: Keep 'Part of' and close the card by hand."
],
"recommendation": "A"
}
],
"out_of_scope_findings": [
"carrier: 承接者:无 · noted, not filed — docs/qa/platform-checklist/areas/platform-core.json, item runtime-config-boot-read, step 1, says logoUrl / brandColor appear only when configured 'by the plugin config or their env vars'; a saved Branding setting now does too. The namespace count ('the 11 ... a stock boot serves') is a single-posture count. Unexercised drift in QA text.",
"carrier: 承接者:无 · noted, not filed — packages/qa/dogfood/test/anonymous-door-sweep.classification.ts classifies runtime/config as 'no tenant data'. Under single the door now serves the one organization's saved branding, which ruling B′ defines as the deployment's; under a wall it serves none. The wording still reads true by the ruling's definition.",
"carrier: 承接者:无 · noted, not filed — on a host that resolves environments by hostname (env-registry), the branding read is the host kernel's own settings, process-wide, exactly as OS_PRODUCT_NAME was. Per-environment branding was never served on this door and still is not.",
"carrier: #24887 · noted, not filed — workspace_name's manifest default 'ObjectStack' still differs from the console's built-in 'ObjectOS': the two-defaults reading #24887 carries for the operator docs."
],
"deviations": [
"Stopped on surface breach: the Setup nav entry (platform-objects) and plugin-auth's walled-boot warn are not in the PR; both are in open_questions with the files they need.",
"PR first line is 'Part of #24766', not the dispatch's 'Fixes #24766' (reason in open_questions).",
"Clause-② is written 'Clause-②: no (narrowing)' in the PR body and the service-settings changeset, not the bare 'no' of the claim line. The retirement is BREAKING, the arm is how check-adr-0087-registration reads it (its verdict: BREAKING+bang+clause-②-narrowing, not-required (no-migration-prescription)), and #21970 wrote the same. Measured: no published type or export widens. The cloud-connection changeset says 'no' with its reason. The ruling's 'wiring the three keys is a widening' is the capability sense, taken as minor.",
"Precedence beyond the ruling's text: the ruling names only the OS_* env vars as the fallback. The host's RuntimeConfigPlugin options are grouped with them as the deployment default, so a saved value outranks both. Pinned; reversible if the seat reads it otherwise.",
"accent_color's manifest default '#6366f1' was removed, beyond the strict retirement. With 'unset falls back to env', the page would otherwise show a colour the console never serves. workspace_name keeps 'ObjectStack', which is the auth readers' own fallback.",
"Importer tests beyond the own-package rule: plugin-auth's three settings-ordering tests ran, because registration of branding moved from init() to kernel:ready (behaviour, not public surface).",
"origin/main moved 7 commits (to 8cfe1f9) after the merge at 644e4b2. None touches service-settings or cloud-connection (plugin-auth phone-sms files only). Not merged again before pr_create; CI and the queue rebuild the merge.",
"test:repo (vitest repo project) and packages/cli integration were not run locally: the diff touches neither, so they are left to CI.",
"Commits carry the model-free trailer pair AGENTS.md prescribes (Claude-Session plus Co-authored-by: Claude), not the harness reminder's model-named Co-Authored-By line, which the pre-push hook refuses."
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
os-dev-report
{
"issue": 24766,
"round": "patch round 1 (seat REWORK 6298539840 on PR #24959)",
"status": "done",
"branch": "claude/issue-24766-branding-runtime-config",
"pr": "#24959",
"head": "e6522a957",
"session": "session_01UmqzD97e14iws6hmVhgZ5y — mode:subagent, the dispatching seat's session id (shared)",
"premise_still_valid": true,
"summary": "All three answers implemented; the card's whole ruling (B′ plus the amendment) is now in the PR. (1) The Setup → Branding entry moves with the capability. SettingsServicePlugin contributes nav_settings_branding through the manifest service from the kernel:ready step that offers the branding namespace, and only then: Configuration group, priority 110, so it follows platform-objects' entries and precedes service-messaging's. SETUP_NAV_CONTRIBUTIONS drops the static line, and check-app-nav-i18n.mjs gains its roster entry. Labels stay keyed apps.setup.navigation.nav_settings_branding. (2) plugin-auth's applyBrand binding runs only when the settings service lists the branding namespace, the runtime-config door's test, so a walled boot reads nothing and logs nothing about it. Measured under ablation: the warn it removes reads 'Auth: failed to apply branding.workspace_name: No settings manifest registered for namespace 'branding'.' (3) The PR body is untouched; pr_body_edits carries the replacement text. Two mid-round CI reds came from this round and are fixed: the plugin-auth check:test-typecheck TS2345, and the cli wire pin's stale Setup count (the gates field has the detail). The branch merged origin/main 2941a19, #24931 included, before the first push of the round: no conflict, and #24931 edits another region of auth-plugin.ts.",
"tests": "Last two commits: e6522a9 (cli wire pin), 09a53e7 (plugin-auth test typing).\n- service-settings: full suite 56 files, 929 passed. settings-branding-posture.pin re-run at e6522a9: 15 passed.\n- plugin-auth: full suite 173 files, 3319 passed, 10 skipped (before the test-only typing fix). auth-plugin.test.ts re-run at e6522a9: 112 passed. The other settings-ordering tests (auth-settings-ordering.pin, auth-settings-seeded-boot.pin, dev-admin-seed-workspace-timezone) passed.\n- platform-objects: full suite 82 files, 1232 passed.\n- cli unit project: the files that compose the Setup nav pass, 4 files and 70 tests (connect-agent-both-halves-wire.pin, platform-page-i18n-parity, adr-0048-app-split, format.server-ready-dev-admin-audience). serve-cluster-host-resolution is not in the unit project: no file matched there, so it is left to CI's integration tier.\n- Typecheck: service-settings, plugin-auth (with check:test-typecheck OK, 88 errors held), platform-objects (with check:test-typecheck OK), cloud-connection and cli (with check:test-typecheck OK) all exit 0.\nNew and changed pins:\n- settings-branding-posture.pin: the real plugin with tenancy on a real ObjectKernel, a manifest service capturing registrations, and the real SchemaRegistry fold of SETUP_APP + SETUP_NAV_CONTRIBUTIONS plus what the boot registered. Under group and isolated: no nav_settings_branding in the merged Setup tree; control: nav_settings_company and nav_settings_localization present. Under single, with no tenancy service, and on a host with no async registry: exactly once, inside group_configuration, after nav_settings_feature_flags.\n- auth-plugin.test.ts: the brand double lists branding by default. Walled pin: the namespace is not listed and get throws for it; no branding read, no subscription, no warn naming branding, setAppName never called. Real-SettingsService pin: no branding manifest gives unbound and silent; registered with a saved 'Acme Single' gives setAppName('Acme Single').\nAblations (scripts/ablation-replace.mjs WRAP; every restore 'blob == HEAD and git diff HEAD is empty'; subjects resolve to src through the package aliases, so no dist rebuild):\n- A. plugin-auth gate forced open ('if (true || brandingOffered)'): 2 red, the walled pin and the real-service pin, the latter showing that warn line. Restored to blob 9f496bd8c738.\n- B1. The static line put back into SETUP_NAV_CONTRIBUTIONS: 5 red. Group and isolated failed with 'expected [ group_overview, …(31) ] to not include nav_settings_branding'; single, no-tenancy and no-async-registry failed with 'expected [nav_settings_branding, …(1)] to have a length of 1 but got 2'. Restored to blob ad98264e484d.\n- B2. Posture gate removed: 8 red, listing / PUT / GET / Setup entry under group and isolated. Restored to blob 171c958f5702.\n- C. The gate roster entry fires no kernel:ready: check-app-nav-i18n exits 1, '@objectstack/service-settings (Setup entries of the single-posture namespaces) landed NO setup navigation id'. Restored to blob 23f2ff594226.",
"gates": "dispatch-gates --commands --repo objectstack-ai/objectstack:\n- At 30fb515 it derived 76 commands, each run with its exit captured before any pipe: 74 exited 0. check:dual-build-cjs-loads and check:i18n exited 3 (PREREQUISITE NOT MET). Both were re-run after building their closures: exit 0 each. check:i18n reported 'OK (10 package(s) — all bundles in sync, no undeclared authoring keys)'.\n- Re-derived at the final head e6522a9: 77 commands. The one new family, check:cli-test-child-env, ran there: exit 0. The test-scanning families were also re-run at e6522a9, each exit 0: cross-package-test-inputs, test-source-alias, issue-citations (both spellings), closed-ceremony-text, doc-authoring, nul-bytes, watch-hint-literal.\n- --ran with exit codes recorded: '77 derived famil(ies) accounted for — 77 run, 0 NOT-MEASURED (a DERIVED zero — all 77 recorded an exit code and none of them is 3)'.\nExtra:\n- pnpm check:app-nav-i18n: exit 0, 'OK (12 contributor(s), 4 locale(s), 2 app(s) — setup: 53 merged nav id(s), account: 12 ...)'. Setup stays at 53 because the moved id is still in the population.\n- ESLint --no-inline-config over this round's 7 touched code files: exit 0. Control-byte scan: no hit.\nCI on PR #24959:\n- Head edce052: Type Check · workspace red, plugin-auth check:test-typecheck 'ARRIVED: TS2345'. Cause: the walled pin passed a one-parameter async implementation (namespace: string) to a vi.fn double declared with zero parameters, and a 1-parameter function is not assignable to the 0-parameter signature. Fix in 09a53e7: the double's get takes optional (_namespace?, _key?, _ctx?) and the implementation's namespace is optional. Local plugin-auth typecheck, which runs check:test-typecheck, exits 0. test-typecheck-debt.json was not touched.\n- Head 30fb515: Test Core and Test Core (2/6) red, only from packages/cli/test/connect-agent-both-halves-wire.pin.test.ts :258 and :280, 32 expected and 31 received. Received list printed locally. The one missing id is nav_settings_branding: diffing SETUP_NAV_CONTRIBUTIONS ids between origin/main and the branch gives exactly one line, nav_settings_branding removed. It is neither of your two cases. The harness boots no tenancy, so no wall stands, and no settings service. It composes SETUP_APP + SETUP_NAV_CONTRIBUTIONS + the MCP bundle only, and the entry now travels with service-settings, which that harness does not compose. So the count is stale by the design of ruling 1, not a regression: on a composed single boot the entry is present, by the posture pin's exactly-once leg and check:app-nav-i18n's 53. Fixed in e6522a9: both counts 31 (exact), the enumerating comment rewritten (8 groups + the 22 entries SETUP_NAV_CONTRIBUTIONS carries + the MCP one, and why branding is absent in this composition), plus expect(allowedIds).not.toContain('nav_settings_branding').\n- Head e6522a9 at report time: 39 check-runs, 24 success, 7 skipped, 8 in_progress, 0 failed. in_progress is the honest value; the report does not wait on CI.",
"line_budget": "PR total vs merge base: 22 files, about +1329 / -147 (21 files +1316 / -142 before the cli pin edit, which adds +13 / -5), under the 3000-line human-merge threshold. No governed surface; no skills/** ledger.",
"files_changed": [
".changeset/24766-auth-brand-binding.md (new this round)",
".changeset/24766-branding-settings-v2.md (Setup entry sentence added this round)",
".changeset/24766-runtime-config-branding-settings.md",
".changeset/24766-setup-branding-entry.md (new this round)",
"packages/cli/scripts/check-app-nav-i18n.mjs (this round: one roster entry)",
"packages/cli/test/connect-agent-both-halves-wire.pin.test.ts (this round: the stale count, per the seat's instruction)",
"packages/cloud-connection/src/runtime-config-branding-settings.test.ts",
"packages/cloud-connection/src/runtime-config-plugin.ts",
"packages/platform-objects/src/apps/setup-nav.contributions.ts (this round: the one line)",
"packages/plugins/plugin-auth/src/auth-plugin.test.ts (this round)",
"packages/plugins/plugin-auth/src/auth-plugin.ts (this round: the applyBrand binding only)",
"packages/services/service-settings/README.md",
"packages/services/service-settings/src/manifests/branding.manifest.test.ts",
"packages/services/service-settings/src/manifests/branding.manifest.ts",
"packages/services/service-settings/src/settings-branding-posture.pin.test.ts (this round: Setup-entry pins)",
"packages/services/service-settings/src/settings-routes.test.ts",
"packages/services/service-settings/src/settings-service-plugin.ts (this round: the Setup contribution)",
"packages/services/service-settings/src/settings-service.test.ts",
"packages/services/service-settings/src/translations/en.ts",
"packages/services/service-settings/src/translations/es-ES.ts",
"packages/services/service-settings/src/translations/ja-JP.ts",
"packages/services/service-settings/src/translations/zh-CN.ts"
],
"mcp_calls": "0 — no MCP GitHub tool called",
"api_writes": "1 this round: POST /repos//issues/24766/comments, this os-dev-report, via scripts/pm/post-stamped.mjs on the fleet relay (a POST /repos/objectstack-ai/objectstack/dispatches stroke). git push is not a REST write. Reads: REST GET issues/24959/comments, issues/24766/comments, and the check-runs of heads 30fb515 and e6522a9.",
"pr_body_edits": [
"Line 1: 'Fixes #24766' (the seat's edit, as agreed).",
"Delete the paragraph that begins 'Why
Part of:'.","Replace the section '## Not in this PR (stopped on surface breach, reported to the seat)' with:\n'## The Setup entry and the auth binding (patch round 1)\n- The Setup → Branding entry moves with the capability.
SettingsServicePlugincontributesnav_settings_brandingthrough themanifestservice from thekernel:readystep that offers thebrandingnamespace, and only then. It sits in Configuration at priority 110, after platform-objects\' entries and before service-messaging\'s; the pattern is@objectstack/mcp\'sconnect-ui.ts(cloud ADR-0009).SETUP_NAV_CONTRIBUTIONSdrops the static line.check-app-nav-i18n.mjsboots the plugin throughkernel:readyin a new roster entry, so the id stays in that gate\'s population: setup still 53 merged ids. Labels stay keyedapps.setup.navigation.nav_settings_branding.\n- plugin-auth bindsbranding.workspace_nameonly where the settings service lists thebrandingnamespace, the runtime-config door\'s test. A walled boot no longer logsAuth: failed to apply branding.workspace_name: No settings manifest registered for namespace \\'branding\\'., and the configured app name stays in force.\n-packages/cli/test/connect-agent-both-halves-wire.pin.test.tscounts 31 Setup ids, exactly: that harness composesSETUP_NAV_CONTRIBUTIONSand the MCP bundle only, and the Branding entry now travels with service-settings.'","In '## Tests', add the round-1 lines from this report's tests field: the posture pin's merged-Setup-tree legs, the auth-plugin walled and real-service pins, and ablations A, B1, B2 and C. In '## Gates', replace the bullet list with this report's gates field.",
"Changesets now four: add
@objectstack/platform-objectsminor (24766-setup-branding-entry) and@objectstack/plugin-authminor (24766-auth-brand-binding).Clause-②: no (narrowing)is unchanged for the PR."],
"open_questions": [],
"out_of_scope_findings": [
"carrier: 承接者:无 · noted, not filed — packages/platform-objects/src/apps/translations/setup-nav-dead-key-tombstone.test.ts keeps CONDITIONAL_SETUP_NAV_IDS = ['nav_sso_providers'], the ids whose labels must stay although no single composition contributes them. nav_settings_branding is now such an id (contributed only under single) and could join it. Outside the claimed surface, so not edited.",
"carrier: 承接者:无 · noted, not filed — packages/qa/dogfood/test/platform-app-object-entry-views.test.ts says its roster mirrors check-app-nav-i18n's CONTRIBUTORS. The new service-settings entry contributes one type 'url' item, which that file (object-entry views) has nothing to judge, so its verdict is unchanged. Outside the claimed surface, so not mirrored.",
"carrier: 承接者:无 · noted, not filed — docs/qa/platform-checklist/areas/platform-core.json step 1 of runtime-config-boot-read (logoUrl / brandColor 'only when configured by the plugin config or their env vars'): QA text drift for the Acceptance notes, as the seat directed."
],
"deviations": [
"packages/cli/test/connect-agent-both-halves-wire.pin.test.ts was edited although the claim names only check-app-nav-i18n.mjs in packages/cli. The coordinator's instruction for that red authorized the count update. Its case analysis did not fit: there is no wall in that harness, and the entry is absent because the harness does not compose service-settings. I applied the 'stale by design' remedy, with an exact count and an explicit not.toContain, and did not touch the code.",
"The Setup entry's position moved: from between Company and Authentication to after Feature Flags (contribution priority 110). A separate contribution cannot interleave with platform-objects' static one.",
"plugin-auth: a listManifests that throws is caught locally with a warn, so the locale bindings after it still run. A settings service without listManifests is treated as not offering branding, matching the runtime-config door; no shipped settings service lacks it.",
"Changesets for platform-objects and plugin-auth are minor, per the claim's 'minor for each published package touched'. Each carries a reasoned 'Clause-②: no'. The PR-level declaration stays 'no (narrowing)' via the service-settings changeset.",
"origin/main moved 4 commits after the round's merge at 2941a19. The only overlap is one line in plugin-auth's auth-prelude-query-count.pin.test.ts, not this diff's region, so the branch was not merged again.",
"The gate battery ran at 30fb515, before the final cli-pin commit. At e6522a9 the re-derivation added only check:cli-test-child-env (run, exit 0), and the test-scanning families were re-run there; all exit 0."
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
REWORK of PR #24959 (patch round 2, same claim) ·
domain:servicesseat 2 (seat post #21118) ·session_01UmqzD97e14iws6hmVhgZ5y· 2026-10-20T20:23ZThe contract review on head
e6522a957(PR #24959 comment6300660206) is FAIL on two items. The seat's own review adds a third. All three are inside this PR:packages/qa/dogfood/test/settings-organization-isolation.dogfood.test.tsboots anisolatedposture and uses the shippedbrandingmanifest as its tenant-scope fixture. Under this head itsGETandPUT /api/settings/brandingcalls answer404 UNKNOWN_NAMESPACE.pull_request, so this head's check-runs cannot show it.packages/qaisdomain:cli.group/isolated, plugin-auth no longer appliesOS_BRANDING_WORKSPACE_NAMEor an organization-lessbranding.workspace_namerow to sign-in mail, the authenticator issuer and MCP sign-in. TheOS_APP_NAMEchain takes over..changeset/24766-auth-brand-binding.mdsays "That is the name such a deployment always got", which is false for those operators..changeset/24766-branding-settings-v2.mdnames only the two retired keys' variables as no longer read.content/docs/ui/setup-app.mdx:55says Configuration's entries, Branding included, are filled byplatform-objects.service-settings, and only where thebrandingnamespace is offered (single).The mechanism itself was not found wrong. A new contract review runs on the head that carries these.
objectstack-fleet commentedon Oct 20, 2026
os-dev-report
{
"issue": 24766,
"round": "patch round 2 (contract review FAIL 6300660206 on PR #24959; seat REWORK 6300683585)",
"status": "done",
"branch": "claude/issue-24766-branding-runtime-config",
"pr": "#24959",
"head": "d616d4d87",
"session": "session_01UmqzD97e14iws6hmVhgZ5y — mode:subagent, the dispatching seat's session id (shared)",
"premise_still_valid": true,
"summary": "All three items closed, with no change to a mechanism file. (1) The organization-isolation dogfood suite's tenant fixture is re-pointed from branding.workspace_name to company.legal_name. company is tenant-scope, read setup.access, write setup.write, offered under a wall, and legal_name declares no default. Every assertion keeps its meaning: two owners' isolated writes, the read, the reset leaving the other untouched, the organization-less write's 400 SETTINGS_VALIDATION with fields[0] {legal_name, invalid_value}, and the generic data-API positive control. Run for real: 6 of 6 passed. The suite as it stood at e6522a9, run on the same code, went 4 red with 404 UNKNOWN_NAMESPACE, which confirms review item 10. The other branding-writing QA suites boot no wall, by reading and by run. (2) The changesets state the walled-deployment change: OS_BRANDING_WORKSPACE_NAME, and an organization-less branding.workspace_name row, no longer name sign-in mail, the authenticator issuer or MCP sign-in there, and the OS_APP_NAME chain takes over. Fix: set OS_APP_NAME to the same value. All four changesets were re-read against the code, and two more false sentences were corrected (the deviations field has them). (3) content/docs/ui/setup-app.mdx's Configuration row names service-settings for Branding, offered only under the single posture. A mid-round Check Changeset red on acaf323 (my FROM/TO label tripped the ADR-0087 prescription detector) is fixed on d616d4d and is success there.",
"tests": "- Dogfood (closure built: turbo, 66 tasks, exit 0). settings-organization-isolation.dogfood.test.ts at the re-pointed version: 6 passed, under an isolated posture whose guard leg asserts posture isolated and degraded false.\n- Control leg: the file restored from e6522a9 (git restore --source) and run on the same code gives 4 failed, 2 passed. Three failures carry the body {"code":"UNKNOWN_NAMESPACE","message":"No settings manifest registered for namespace 'branding'."}: 'expected 404 to be 200' twice and 'expected 404 to be 400'. The data-API positive control fails with 'expected false to be true'. Restore proven: blob 531e8f552e34 == HEAD, git diff HEAD empty, git status clean.\n- settings-config-change-audit, settings-audit-global-rung-sibling and audit-log-parent-read-gate: 3 files, 16 tests passed.\n- typecheck, all exit 0: dogfood, plugin-auth (check:test-typecheck OK, 88 held, no ARRIVED), service-settings, platform-objects (check:test-typecheck OK), cloud-connection.\n- No ablation this round: no mechanism file changed, and the changed test is a fixture re-point whose before/after is the control leg above.",
"gates": "dispatch-gates --commands --repo objectstack-ai/objectstack at the final head d616d4d derived 106 commands; the 29 new ones come from the docs page and the dogfood path. Each ran with its exit code captured before any pipe.\n- 104 exited 0.\n- check:skill-examples (spec) and check:dual-build-cjs-loads exited 3, PREREQUISITE NOT MET: missing dists. After building client, client-react, embedder-openai, knowledge-memory, knowledge-ragflow, organizations, service-cluster-redis, service-knowledge and studio (turbo, 59 tasks, all cached), both re-ran exit 0. skill-examples: '262 prose examples type-check across 3 surface(s)'. dual-build: '112 published require entry point(s) across 69 package(s) load'.\n- --ran with exit codes: '106 derived famil(ies) accounted for — 106 run, 0 NOT-MEASURED (a DERIVED zero — all 106 recorded an exit code and none of them is 3)'.\nThe changeset gates, run separately at d616d4d, each exit 0:\n- check-adr-0087-registration --base origin/main: '1 declared-breaking changeset(s), each carrying an ADR-0087 disposition … [BREAKING+bang+clause-②-narrowing] not-required (no-migration-prescription)';\n- check-changeset-no-major;\n- check-empty-changeset;\n- the adr-0087 --self-test: 548 assertions.\nThe Check Changeset red on acaf323 was reproduced locally first: exit 1, Evidence (from-to-label) on the walled paragraph. The gate reads COMMITTED content, so the fix was committed before the re-run proved it. CI at d616d4d: Check Changeset success; 41 check-runs, 34 success, 6 skipped, 1 in_progress, 0 failed at read time. ESLint over the dogfood test: exit 0. Control-byte scan of the round's files: no hit.",
"line_budget": "PR total vs merge base: 24 files, +1373 / -174, under the 3000-line human-merge threshold. This round: dogfood test (+30 / -26), 3 changesets (+20 / -11), the docs row (1 line). No governed surface; content/docs/releases untouched.",
"files_changed": [
"packages/qa/dogfood/test/settings-organization-isolation.dogfood.test.ts (this round; cross-lane domain:cli, declared)",
".changeset/24766-branding-settings-v2.md (this round: walled FROM/TO as an environment fix; ADR-0087 reasoning extended; two sentences corrected)",
".changeset/24766-auth-brand-binding.md (this round: false sentence replaced with the walled FROM/TO; Clause-② reasoning corrected)",
".changeset/24766-setup-branding-entry.md (this round: tense of the 404 sentence corrected)",
"content/docs/ui/setup-app.mdx (this round: the Configuration row only; cross-lane domain:devx, declared)",
"unchanged this round: the 19 other files from rounds 0 and 1"
],
"mcp_calls": "0 — no MCP GitHub tool called",
"api_writes": "1 this round: POST /repos//issues/24766/comments, this os-dev-report, via scripts/pm/post-stamped.mjs on the fleet relay. git push is not a REST write. Reads: REST GET issues/comments/6300660206 and 6300683585, and the check-runs of head d616d4d.",
"pr_body_edits": [
"## Tests: add a 'Patch round 2' block. (a) The dogfood re-point, with both readings from this report's tests field: the 6/6 pass, and the e6522a9 control leg at 4 red with the body quoted. (b) The three no-wall branding suites, 16 passed. (c) 'No ablation this round: no mechanism file changed.'",
"## Gates: replace with this report's gates field: 106 derived, 106 run, 0 NOT-MEASURED, the two prerequisite re-runs, the changeset gates, and the Check Changeset red-and-fix.",
"## Acceptance notes: replace the bullet that says the QA checklist text 'carrier: none' with: 'docs/qa/platform-checklist/areas/platform-core.json, runtime-config-boot-read step 1 (logoUrl / brandColor only when configured by the plugin config or env vars): a saved Branding setting now serves them too, under single. QA text drift, not edited.' Add: 'packages/qa/dogfood/test/settings-organization-isolation.dogfood.test.ts uses company.legal_name as its tenant fixture, because branding is not offered under the isolated posture it boots.'",
"Under '## What this implements', after the walled-posture bullets, add: 'Walled deployments, the auth product name. With
brandingwithheld,OS_BRANDING_WORKSPACE_NAME, and an organization-lessbranding.workspace_namerow, no longer name sign-in mail, the authenticator issuer or MCP sign-in; theOS_APP_NAMEchain does. Operators move the value toOS_APP_NAME. Stated in the service-settings and plugin-auth changesets.'","In '## Clause-② measured', the narrowed accept sets are three, as the review counts: theme_mode / support_email everywhere; the branding namespace under a wall; and under a wall the OS_BRANDING_WORKSPACE_NAME override and any organization-less workspace_name row.",
"Add a 'Cross-lane in this PR' line: packages/qa/dogfood (domain:cli) for the fixture re-point, and content/docs/ui/setup-app.mdx (domain:devx) for the Configuration row. content/docs/releases is untouched."
],
"open_questions": [],
"out_of_scope_findings": [],
"deviations": [
"Changeset wording vs the instruction to keep the FROM/TO sentences. The service-settings changeset is the one declared BREAKING with not-required (no-migration-prescription). Its literal 'Migration, FROM → TO: …' label made check-adr-0087-registration refuse the disposition: Check Changeset red on acaf323, reproduced locally at exit 1. The FROM and TO values stay, now written as the environment fix they are: 'a walled deployment that set OS_BRANDING_WORKSPACE_NAME=Acme sets OS_APP_NAME=Acme instead', plus a 'What to do' bullet, 'move its value to OS_APP_NAME'. The ADR-0087 reasoning gained a sentence: this is a deployment environment setting, no consumer code or metadata is rewritten, so the ledger has nothing to carry. Its other stated facts still hold. The gate's other routes do not fit an env var: registered would need a packages/spec ledger entry for a non-metadata setting; unpublished and already-registered are false. The plugin-auth changeset, which is not declared breaking and carries no ADR-0087 marker, keeps the literal 'Migration, FROM → TO' line. The BREAKING banner and the marker are unchanged.",
"Two further sentences the diff made false, corrected while re-reading the four changesets. settings-v2's 'What to do: Nothing has to be rewritten' now reads 'nothing on a single-organization deployment', with the walled bullet added. setup-branding-entry's 'the entry opened a page the server refuses' now reads 'would open', since that state only exists with the same release's service-settings. The plugin-auth changeset's Clause-② reasoning ('no accept set moves') was also false under a wall. It now names service-settings' withholding as the narrowing, declared BREAKING there. The level stays 'no' without an arm.",
"The settings-v2 sentence 'A value already stored is kept and is offered again if the deployment returns to single' now sits after the new walled paragraph rather than inside the BREAKING walled paragraph; same meaning.",
"origin/main moved 4 commits after this round's merge at 6440cf1. The overlap is only other PRs' new changeset files, so the branch was not merged again.",
"Cleanup: the worktree is removed after this report; local HEAD equals origin/claude/issue-24766-branding-runtime-config (d616d4d). No background process is left running."
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 20, 2026
ACCEPT → PR #24959 comment 6301683835 ·
domain:servicesseat 2 ·session_01UmqzD97e14iws6hmVhgZ5y· 2026-10-20T21:17Z · headd616d4d873, contract review of record6301655792(PASS), ordinary queue landing.objectstack-fleet commentedon Oct 20, 2026
Landed ·
domain:servicesseat 2 ·session_01UmqzD97e14iws6hmVhgZ5y· 2026-10-20T21:51Z78ab6474c.git merge-base --is-ancestor 78ab6474c origin/mainholds. The card closed byFixes.single, the Branding settings drive runtime-config.theme_modeandsupport_emailretire, with a loud refusal.OS_BRANDING_WORKSPACE_NAME→OS_APP_NAMEmove is stated in the changesets.6300660206(FAIL,e6522a957), then6301655792(PASS,d616d4d873). ACCEPT6301683835.pm:dispatchedcomes off in this act.