Surfaces live connection health for the active instance in the sidebar
and probes localhost:8000 on the first-run choose-type screen so users
running Honcho locally can connect in one tap.
- useHealthStatus hook polls checkConnection every 30s via TanStack Query
- HealthDot component renders a colored status dot with tooltip
- choose-type screen silently probes http://localhost:8000 once; on
success it surfaces a "Detected Honcho at localhost:8000 — tap to
connect" banner that opens the self-hosted form
Adds a "choose-type" step to the settings flow so users can pick between
Honcho Cloud (https://api.honcho.dev, API key required) and Self-Hosted
(URL + optional token) when creating a connection. Multi-instance support
already exists in the data layer, so cloud and self-hosted instances can
coexist.
- new HONCHO_CLOUD_URL constant and isCloudInstance helper in config.ts
- SettingsForm accepts a preset prop; cloud variant locks the endpoint
and enforces an API key
- InstancesManager gains a ConnectionTypeChooser entry point and renders
a Cloud icon for cloud instances in the list
- unit tests for both preset paths and cloud edit-mode detection
Replace single localStorage config with a named-instance store
({ instances: Instance[], activeId }). Adds an instances manager on
the settings page (list / add / edit / delete / activate) and a
sidebar switcher for quick swaps. Existing single-config users are
migrated transparently on first load.
Switching or deleting an instance clears the TanStack Query cache so
data from another deployment never bleeds into the active view.
Add /explore redirect route that maps Honcho's deep-link shape
(?workspace=...&view=...&session=...) onto our existing flat routes,
so any app.honcho.dev URL works against a self-hosted instance by
swapping the host.
Wire tauri-plugin-deep-link to register the openconcho:// scheme on
desktop and forward incoming URLs into the router on launch and at
runtime.
Previously the release workflow updated Cargo.toml's version via sed
but never refreshed Cargo.lock, leaving it one version behind after
every release. Add cargo update for the openconcho package to the
prepareCmd, and add Cargo.lock to @semantic-release/git assets so it
ships in the release commit.
Also bumps the lagging 0.5.1 -> 0.5.2 lockfile entry that the
0.5.2 release missed.
Settings page was rendering Outlet directly, omitting the Sidebar nav.
Adds a playwright e2e test asserting sidebar visibility on both
dashboard and settings routes.
Bug 1: On a fresh load with no saved config, RootLayout returned `null`
while a useEffect-driven `router.navigate()` fired, leaving a blank screen
until the user manually refreshed. Move the redirect into the root route's
`beforeLoad` so it happens synchronously during route resolution and the
settings form renders on first paint.
Bug 2: `DemoProvider` was mounted inside `RootLayout` only on the
non-settings branch, so any component reading `useDemo()` outside that
branch would throw "useDemoContext must be used within DemoProvider".
Hoist `<DemoProvider>` to `main.tsx` so the context is available app-wide.
Adds vitest + RTL setup with regression tests for both behaviours.
Camo had cached "repo not found" SVGs from before the repo had releases.
Adding query params changes the camo hash so GitHub re-fetches from shields.io.
Adds a `tauri` task to turbo.json with dependsOn ["^build"] so that
desktop#tauri automatically triggers web#build first via the workspace
dependency graph. The tauriScript routes tauri-action through turbo
rather than invoking tauri directly, eliminating the need for an
explicit build step.
Moves web frontend build into tauri-action's beforeBuildCommand so
Turborepo's dependency graph drives the ordering rather than a
detached workflow step that can be reordered away from the action
that needs it.
- Add @semantic-release/npm (npmPublish: false) to bump root package.json
- Add prepareCmd to exec plugin to sync Cargo.toml on each release
- Add Cargo.toml to @semantic-release/git assets
- Manually advance package.json and Cargo.toml from 0.1.0 → 0.4.0
Covers workspace IDs, session IDs, peer IDs in breadcrumbs and titles,
server base URL in sidebar, webhook URLs/IDs, and session metadata source
tags across all 11 components.
