[morgmart]

Problem

When you run Buzz as a browser build in live development, Builderlab sign-in goes through the dev broker (browser-host/builderlab.mjs). The broker still sends product=builderlab on /v1/auth/login, so the hosted login shows the generic Builderlab page. The shipped desktop app shows the Buzz page ("continue to Buzz").

Change

The dev broker now sends product=buzz, so browser-build testing matches the desktop.

The desktop sign-in was originally part of this PR. On main, #2576 moved it into native code (nsec_backup.rs), and that code already sends product=buzz. This branch now takes main's version of those files.

Safety

This is development-only. Shipped builds don't use the broker.

product doesn't affect account access. kgoose checks it against an allowlist and forwards it as ext-product. Neither the access policy nor the callback check reads it. Only the hosted login pages in ext-builderbot-ui use it, to pick the Buzz or Builderlab look.

Screenshots

This PR doesn't change any Buzz UI. The only visible effect is the hosted login page during browser-build development.

Testing

• vitest run browser-host/builderlab.test.mjs (53 passed, after merging main)
• biome check passes on the changed files.

🤖 Generated with Claude Code

[wesbillman]

🤖 Carl, an automated reviewer, commenting via Wes's GitHub account.

Verdict: The code change is right, with one item to resolve before merge (inline). Switching to product=buzz matches key backup, and buzz-app has no other product=builderlab caller. On the backend, current cash-server d613c3d5 matches the Safety section: kgoose allowlists product and forwards it only as ext-product. It never reaches pending login, callback validation, provisioning, session or token fields.

Gap: On the hosted page the Buzz variant changes more than branding. Details and exit criteria are inline.

Optional follow-up (Wes's call, not this PR): After sign-in the loopback page is still titled "Builderlab sign-in" and shows the Builderlab mark (src-tauri/src/oauth_callback/page.html:6,11). So the user goes from a Buzz-branded hosted page to a Builderlab-branded one. Key backup already does the same.

CI is green at 73e51f29. Nobody has reproduced an authenticated production login.

[kalvinnchau]

🤖 One documentation durability finding; deployed Auth0 renderer remains unverified.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account.

No new actionable findings in the documentation follow-up at head 0302c5fcee76e9281de2f1274a25bf8a3c9d624a (base e8b7165b1739321869d8fecd53d791b8de497bd4). The complete endpoint diff from previously reviewed 73e51f2920f6f685c03e3a3bd5fd4acb580069d4 changes only the README: production code and tests are unchanged. This qualifies for the small-follow-up solo exception.

The README and PR Safety section now distinguish the custom login page from the classic Universal Login template, addressing the prior wording finding. The author’s shipped-origin confirmation is recorded; I did not independently verify deployed configuration or the active Auth0 renderer.

Validation limits: source and public-description review only; no attached images, local tests, app execution or authenticated sign-in exercised. The current check snapshot reports CI required failed, with JavaScript (4/4), Chromium (2/9) and WebKit (3/14) failures; Windows validation is skipped. Those failures were not diagnosed in this documentation review. Native success/error/retry focus behavior remains unexercised. This is a COMMENT review, not approval or merge-readiness confirmation.