Adds @vitest/coverage-v8 (catalog-pinned), a test:coverage script wired
through turbo (inputs + coverage/** output), and coverage thresholds set
to a floor measured on main (lines 18 / funcs 10 / branches 10 / stmts
17 against current 19.3/11.4/11.7/18.9). Ratchet upward as tests grow.
Adapts the coverage config from @BenSheridanEdwards's fork; the multi-job
CI fan-out from that branch was intentionally left out.
Co-authored-by: Ben Sheridan-Edwards <BenSheridanEdwards@users.noreply.github.com>
* feat(desktop): auto-discover Honcho instances on localhost
First-launch and on-demand discovery of running Honcho instances on
127.0.0.1:8000-8100. Desktop-only — the browser can't port-scan due to
CORS, so the scan runs in the Tauri Rust shell.
- New Rust command `discover_honcho_instances(start_port?, end_port?)`
in src-tauri/src/discover.rs: parallel TCP probe of each port with
150ms connect timeout + 250ms total request budget, looking for a
/health endpoint returning `{"status":"ok"}`.
- New TS helper `discoverHonchoInstances()` in src/lib/discovery.ts:
detects Tauri runtime; web build degrades to an empty result.
- `suggestNameForInstance()` fetches the first workspace and derives a
friendly name from its id ("neo-personal" -> "Neo"). Used to seed the
Name field for each discovered instance.
- `DiscoveredInstances` component: list of found instances with
editable suggested names + per-row checkbox + "Add N instances"
button. Rows are pre-checked by default and filter out already-
configured baseUrls.
- Wired into `InstancesManager`:
- First launch (no instances): renders above the connection-type
chooser with autoRun=true. User sees results immediately.
- With instances: adds a "Discover instances" button to the list
view that opens the discovery flow on demand.
- Both paths gate on `isTauri()`; the web build keeps its existing
behaviour unchanged.
Adds tokio (with net + io-util + time + rt + macros) and futures to
the Tauri shell to get async TCP + join_all.
Tests:
- deriveNameFromWorkspaceId handles hyphenated, multi-segment, and
no-hyphen ids
* test(desktop): add probe tests including live Hermes stack integration
- rejects_inverted_port_range
- ignores_ports_with_no_listener
- finds_live_hermes_stacks (#[ignore]d; opt-in with --ignored)
The ignored test exercises discover_honcho_instances against ports
8000-8010, expecting exactly [8001, 8002, 8003, 8004, 8005]. Verified
locally — the probe finds all 5 stacks in <10ms.
---------
Co-authored-by: Agents <agents@Jarviss-Mac-mini.local>
Filed the upstream feature request asking /queue/status to surface
per-work-unit observer/observed, specialist phase, and token telemetry.
Panel now links to the concrete tracking issue instead of a pre-filled
new-issue form. Re-captured the showcase screenshots so the visual
state matches.
Wires up the DEV-only /dream-progress showcase to a Playwright script
that captures idle/active/stalled variants for documentation. Also
regenerates routeTree.gen.ts to include the new queue + showcase routes
and folds in Biome formatter fixes.
Run `node scripts/screenshot-dream-progress.mjs` from packages/web with
the dev server up to refresh the images.
- pickQueueRefetchInterval picks 2.5s when work is active, 10s otherwise
- useStaleQueueDetection only flags after 30 min without forward progress
- stall anchor resets when completed advances or all work finishes
Watching dreams was a 5-15min black box. Now a dedicated
/workspaces/:id/queue route polls /v3/workspaces/:id/queue/status
every 2.5s while work is in-flight (10s when idle) and surfaces a
warning when in-progress work hasn't advanced the completed count
for >30 minutes.
The Honcho API only exposes aggregate counts (no observer/observed
pair, specialist phase, or token telemetry per work-unit), so the
panel links out to an upstream issue for those.
- queries: adaptive refetchInterval via TanStack Query callback form
- hooks/useStaleQueueDetection: client-side stall detection
- routes/workspaces_.\$workspaceId_.queue: dedicated live view
- routes/_dev.dream-progress: DEV-only showcase for screenshots
- WorkspaceDetail: new "Queue & dreams" nav card
- Moves docs/seed-kits/*.png into docs/seed-kits/light/.
- Adds docs/seed-kits/dark/ with the same three panels rendered in
the dark theme.
- Updates the capture script to loop over both themes by setting
openconcho:theme in localStorage and the matching colorScheme on
the browser context.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a /seed-kits page where users can author named "kits" of card
lines (e.g. "Personal core", "Work context") and one-click apply them
to any peer across any registered instance. Removes the chore of
manually re-typing the same identity facts into multiple agents.
Built-in starter kits are read-only but forkable. User kits live in
localStorage. The apply flow shows a side-by-side merge preview that
dedupes by the line's prefix (text before the first ":"), so applying
a kit with "Name: Ben Sheridan-Edwards" to a peer whose card already
has "Name: Ben" replaces the line rather than duplicating it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds createScopedClient() — an openapi-fetch client bound to a specific
Instance (rather than the active one in localStorage) — and the
useScoped* TanStack Query hooks (workspaces, peers, peer representation,
peer card) with per-instance query-key isolation so caches never collide
across instances.
Foundation for multi-instance features (seed kits, desktop
auto-discover) that read from non-active instances.
Co-authored-by: Ben Sheridan-Edwards <BenSheridanEdwards@users.noreply.github.com>
main.tsx wraps the app in DemoProvider > MetadataProvider, but the
app.test.tsx render helpers only wrapped with DemoProvider. Since
e490d91 added useMetadata() to Sidebar, the routed app threw
"useMetadataContext must be used within MetadataProvider" in tests;
the error boundary swallowed the tree and the first-load assertion
failed. CI has been red on main since that commit.
Mirror the production provider nesting in both render sites.
Introduce MetadataContext + useMetadata hook backed by localStorage and
wire a Braces button into the sidebar footer that toggles raw metadata
visibility across the app. Replace per-page collapsible metadata in
PeerDetail and WorkspaceDetail with a global animated reveal styled
distinctly (warning-colored card) to signal raw payload. Also adopts
the shared Breadcrumb in both detail pages.
Detect active workspace via fuzzy matchRoute against /workspaces/$workspaceId
and reveal an animated sub-nav with links to Peers, Sessions, Conclusions,
and Webhooks for that workspace. Sub-nav collapses smoothly when leaving
the workspace context.
Replace ad-hoc back-arrow and inline breadcrumb markup in PeerList,
SessionList, SessionDetail, ConclusionBrowser, and WebhookManager with a
single router-aware Breadcrumb. Demo-aware via useDemo() so workspace
and entity IDs render masked when demo mode is active.
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.
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.
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.
safari13 causes esbuild to fail on modern destructuring patterns
from TanStack Router/Query. In 2026, all WebKit versions that can
run Tauri v2 fully support esnext. Use chrome120 for Windows.
