[baxen]

Why

New users had to sign in to Builderlab twice in Settings: once under Builderlab hosting (communities) and again under Builderlab agents. This PR gives them one sign-in on one page.

What changes

• One page. Settings → Plugins → Builderlab, with the Block logo as its icon. It has three sections: Account (sign in or out), Communities (identity link, your communities, create) and Remote agents. The Hosted communities plugin (block.hosted-communities) is folded into block.builderlab under communities/, and its separate registration is removed from the bundle list, the plugin manager and the native grant test.
• One sign-in. On desktop, communities now use the Builderlab plugin's existing sign-in instead of their own product=buzz login. The product login parameter only sets the branding on the sign-in page; the kgoose BbidentityAuthService uses it as an ext-product hint, so both credentials are the same session type. Signing out anywhere signs out everywhere.
• Configured server. Communities go to the configured BUZZ_BUILDERLAB_URL instead of a hardcoded https://app.builderlab.xyz. Release builds already set it to production, so the saved pending-deletion origin stays the same there. Builds without the URL now show the unavailable notice for communities.
• No identity race. After sign-in, communities wait for sign-in's automatic identity link to finish before reading the account. That way a first sign-in shows "Buzz identity connected" rather than briefly offering Connect.
• The Create community links in the community picker and landing page now open the new page.
• The remote agents list now uses the same SettingsGroup rows and header Refresh action as the communities list.
• Live development with a pinned viewer (VITE_BUZZ_LIVE=1) keeps the broker backend and its own sign-in. That mode has no native signer to bind with.

A second UX pass is expected. This PR only combines the two pages with the existing design-system parts: Header, InlineHeader, SettingsGroup, EmptyState and Button.

Screenshots (fixture render, signed in, demo data)

These come from a throwaway fixture, not the native app. It loads the real Builderlab plugin(s) through the real plugin runtime and settings cards, with the in-process test relay as the community relay. The native bridge and Builderlab responses are stubbed with demo data: the account, communities, agents and throwaway keys are all fake. The before shot is from the base commit 911526a87, which had two separate Settings pages, shown stacked here. Each needed its own sign-in.

Before (light)

After

Light	Dark

Validation

• vitest run src/shared/design-system src/app src/features/communities src/bundled: 4938 passed.
• cargo test -p buzzodz-plugins: passed.
• cargo check --tests in src-tauri: passed.
• design:check and the icon checks: passed.
• Pre-commit and pre-push hooks: passed.
• native.test.ts was rewritten for the shared session. It covers allowlisted routes, the 401 sign-out, stale-session guards on binding, waiting for the link, and nsec_backup_retry now using the builderlab source.
• index.test.tsx checks that the desktop card shows one Sign out button and communities with the identity connected, and that live development stays on the broker.

Not yet done: an agent run of the native desktop app, a human test, and an independent agent review.

Follow-ups / notes

• The native nsec_backup Source::Hosted variant no longer has a frontend caller. I left it in place to keep this PR to the frontend; it can be removed separately.
• Saved plugin flags: anyone who had disabled Builderlab now also loses communities. A saved flag for block.hosted-communities is ignored, like the flags of other removed bundles.

🤖 Generated with Claude Code

[kalvinnchau]

🤖 Code-only review: repair the stale browser journeys before approval; required CI fails before their behavioral assertions. Additional findings cover expired-session recovery and an obsolete sign-in destination. Source, tests, and hosted CI evidence were reviewed; no application/browser or live Builderlab validation was performed.

[kalvinnchau]

🤖 Approved after code-only re-review of afae371. The browser journeys now use the consolidated Builderlab destination without weakening their behavioral assertions, community-route 401 handling ends only the initiating session, and app sign-in guidance points to the correct section. The new held-response test covers stale and current credentials; required CI now passes.

No actionable findings remain. Review covered source, regression tests, and hosted CI evidence; no local application/browser or live Builderlab login/binding validation was performed. The older /me late-response test still covers cancellation before dispatch rather than an in-flight response; this is a nonblocking coverage gap with the production guard present.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account.

One P2 inline: keep a local retry after a transient Communities account-check failure. Rocket, Mantis and Groot supplied independent review lanes. Reviewed head afae3717f37a0fb626f8f303deafc7286c4863f5, base 9bff16b421915ee742921e5a972d685a76e0d04f, including all three fixture screenshots. Hosted CI required was successful; Windows native validation was skipped. Source-only: no tests or app execution; native sign-in, keyboard/focus recovery and human acceptance remain unverified.

🤖 Withdrawing approval: the transient community account-check recovery defect in discussion_r4409305663 is confirmed at afae371. Add local retry and regression coverage before renewed approval.

[kalvinnchau]

🤖 Reviewed at ead0883. The local account-check retry repair addresses the prior recovery finding while preserving session/lifecycle guards, 401 sign-out, and no deletion replay. No actionable findings from source review. Tests and runtime flows were not executed; native retry/account-replacement integration coverage remains limited.