Remove Home, start in Messages, and keep Channels enabled

[morgmart]

What this does

Removes Home and makes Messages the default destination. Home no longer appears in tabs, search, or error actions. Old Home links still open Messages without flashing the deleted page or adding a back-button step.

Channels is permanently enabled across browser, desktop, and CLI management. Previously saved “disabled” preferences no longer disable it, and Settings has no Channels switch. Other plugins retain their normal controls.

Implementation boundaries

• Deletes the Home component and launch flag, rather than retaining a hidden feature or alternate build.
• Retains the legacy version-1 Home navigation target for compatibility. It resolves to Messages before paint within the same navigation attempt and visit, preserving cancellation, history, and stale-completion protection.
• Enforces required Channels in both the browser storage adapter and native plugin manager, not just Settings. Rejected disable requests do not write preferences; old disabled values remain inert without a destructive migration. Invalid browser configuration still enters recovery.
• Failed destinations offer Settings. Loading, failure, and plugin-configuration recovery remain available.
• Includes the startup-order repair discovered during this PR: optional template loading begins after initial channel discovery, avoiding cancellation of the initial request. Shared cancellation and access rules are unchanged.
• Updates existing product documentation to match the removal and required-Channels policy. No custom styling or new flag service.

Validation

Current pushed head: b910d79427acb176798e585be063b34153c40d15.

• Mandatory push checks passed at this head: formatting/lint, sadscan, TypeScript, 254 test files / 2,622 tests, and design-system type/color/contrast/foundations/icons/adoption guards.
• On the Home-deletion working tree before the final documentation/test cleanup, 40 browser checks passed across Chromium and WebKit using launch-home.spec.mjs appearance.spec.mjs navigation-repairs.spec.mjs navigation-lifecycle.spec.mjs --no-deps. Filename matching also selected profiles-appearance coverage.
• Required-Channels validation before Home deletion: 40 browser checks passed across Chromium/WebKit for launch, layout, and Settings-related files. An initial WebKit profile case failed, then passed unchanged on rerun; the initial run was not clean.
• Native plugin-manager package: 10 unit tests + 13 management tests passed. Browser/native tests cover saved-disabled preferences, reopen, rejection without writes, and independent optional-plugin controls.
• Production app and design-system builds/typechecks passed; only large-chunk warnings were reported.
• Independent lifecycle and coverage reviews were clear (source-only). Requested documentation and whitespace cleanup is included in the final commit.
• Hosted DCO passed. Hosted JavaScript, Rust, browser journeys, and browser measurements were pending when checked after the push. Windows native validation was skipped.

Coverage changes and remaining gaps

The obsolete Home-enabled browser suite and its alternate build fixture are deleted. Still-relevant typography and spacing assertions moved into the regular appearance suite. Launch coverage retains no-Home-flash checks, responsive tabs/search, legacy links, reload, back/forward, required-Channels normalization, and corrupt-configuration recovery. Existing cross-page tests use optional pages where disabling/unmounting remains supported.

The startup-order regression uses an explicit discovery gate and failed before its production repair; the affected browser-file run then passed 38/38. Those historical checks are not claimed as a full-suite run at the current head.

The updated design-system viewer host-ownership browser check did not execute because its configured port 1444 was occupied. The existing server was left untouched. Native GUI/packaging smoke testing and the full browser suite have not been run locally for this head; hosted validation remains outstanding.

Earlier visual reference

This screenshot uses synthetic browser-test data and test-only plugin tabs. It predates the community rail merged from main; it is not a current-head screenshot.

Originating Buzz conversation: buzz://message/94b01414-b886-445f-80f0-183554fd9388/0c8a02dc0ae5fd3feb11a1960bc6a3487aa108e4ba49e63379a4d67e858e24ba

[wesbillman]

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

Review clear: no actionable blockers found. Reviewed efdb0245ab51bdad60f0e9b55dbe300c006c57dd against fe897a10f1bfa6590092b0f82d943e9b555c42c3, including an independent navigation-surface review.

Home is hidden through one build-time authority, legacy/default Home targets resolve within the same visit, and Settings remains reachable through destination and configuration recovery. The template-loading repair reuses initial channel-authority readiness rather than widening shared cancellation behavior.

Existing exact-head CI passed, including 540/540 Chromium/WebKit journey cases with no flaky or skipped cases. The launch, enabled-Home and startup-template regressions passed in both engines without retries. This was source-only review; I did not execute PR code or rerun CI. Windows native validation was skipped, and native packaging/live release acceptance remains outside this verdict.

Non-blocking documentation follow-up: docs/shell-design.md still describes unconditional Home; document its launch gate when updating that page. No source fix is required by this review. This is a comment, not an approval.

[wesbillman]

We could probably just delete home completely from the codebase and re-add back whatever it is we actually want when the time comes instead of feature flagging it here