Using a metrics object as a useEffect dep causes the loop:
onMetrics → setMetricsById → Dashboard re-renders → ServerWorkspaceRows
re-renders → useQueries runs → TanStack Query cache subscriber fires
(Sidebar's setNow) → query result objects are new references → metrics
useMemo returns new object → effect dep changed → onMetrics again → ∞
Fix: depend on the five primitive values (workspaceCount, conclusionCount,
queueActive, queuePending, health) directly. React compares primitives by
value, so the effect only fires when actual data changes, not on reference
churn from re-renders.
Also adds server-workspace-rows.test.tsx with three focused unit tests:
correct health:ok report, stability after load (no re-fire), and health
transition coverage.
lastSeen tracked workspacesQ.dataUpdatedAt which updates on every background
refetch, creating a new metrics object reference each cycle. The useEffect
dep on metrics then fired unconditionally, calling onMetrics → setMetricsById
→ Dashboard re-render → another refetch → infinite loop.
computeFleetAggregates never reads lastSeen, so reporting it upward was
pointless. Hardcode null and drop it from the dep array entirely.
If the user filters to a specific server and that instance is then deleted
(e.g. from Settings), shownInstances becomes [] — empty table, no message.
A useEffect resets the filter to ALL_SERVERS whenever the selected ID
disappears from the instances list.
Remove lastSeen from metricsEqual in ServerWorkspaceRows: computeFleetAggregates
never reads lastSeen, so comparing it in metricsEqual causes background TanStack
Query refetches (dataUpdatedAt changes) to trigger spurious onMetrics callbacks,
cascading into a Dashboard → ServerWorkspaceRows render loop that hits React's
100-render limit in CI.
Add staleTime: Infinity to the test QueryClient to prevent background refetches
from interfering with test assertions.
Implements Phase 1 of the UI navigation rework (docs/superpowers/specs/
2026-06-02-ui-navigation-rework.md): the Dashboard now lists every workspace
across every configured server as <workspace> (<server>), filterable by server,
with cross-server aggregate cards (reusing computeFleetAggregates). Opening a
workspace activates its server then drills into the existing detail route.
Per-server fan-out lives in a ServerWorkspaceRows child (rules-of-hooks safe,
mirrors FleetRow). Fleet removed from the sidebar nav; the /fleet route is left
intact for now (full removal deferred to avoid churning fleet.test.tsx while #54
is open).
Adds a new /fleet route that shows a fleet-wide overview of all
configured Honcho instances. Each row renders per-instance metrics
(workspace count, total conclusions, queue activity, last seen, health)
by fanning out scoped fetches via createScopedClient, and aggregates
into top-level metric cards.
Reuses the Phase 2 scoped-client pattern. Extends compareQueries.ts
with useScopedQueueStatus and useScopedConclusionsCount, plus option
builders so useQueries can fan out per-workspace requests inside
FleetRow without duplicating query logic.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Human peers surface as raw ids (WhatsApp `…-lid`, UUIDs). Read an
optional `display_name` from peer metadata and prefer it over the id in
the peer header and breadcrumb, with the raw id kept as a sub-caption.
An inline edit on the header writes `display_name` via useUpdatePeer
(merging existing metadata); blank clears it. Falls back to the id when
unset.
Closes#32.
* 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.
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
Lets users fire one query at every Honcho reasoning level (minimal / low /
medium / high / max) in parallel and compare answers + latency side-by-side
in a 5-column grid.
- New route: /workspaces/:ws/peers/:peer/playground
- New component: DialecticPlayground with per-column state, level checkboxes
to skip expensive levels, and a single Run button that fans out via
Promise.all
- Extends useChat() to accept an optional reasoning_level parameter (was
hardcoded to "low")
- Adds a Playground button next to Chat on the peer detail page
- Tests cover the parallel fan-out (peak concurrency = 5, no serial
awaiting) and per-column latency measurement
- Screenshot Playwright spec (idle / mid-flight / settled) drives the
images in docs/screenshots/ — regen with PLAYWRIGHT_BASE_URL=... pnpm
exec playwright test e2e/playground.screenshots.spec.ts
- packages/web/e2e/dreams.spec.ts: 4 tests covering sidebar entry,
heading/breadcrumb resolution, mocked-API clustering into rows with
count chips, and the premise-tree expansion path. Uses a function
matcher for context.route so the trailing ?page=&page_size= query
string doesn't break a glob.
- docs/screenshots/: dark + light mode list and expanded-detail PNGs
captured at 2880x1800 (retina) via playwright against the dev
server with a tiny mock Honcho.
- DreamList.tsx: add a literal space to CountChip's label fragment so
the rendered text reads "3 explicit" instead of "3explicit" (gap-1
styles the visual layout but doesn't add a text-node space). Better
for screen readers, copy/paste, and assertion via toContainText.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Dreams are currently a black box — to benchmark Tier L models on dreamer
induction quality we need to see what each model produced. This adds a
workspace-scoped /dreams route that surfaces every dream run as a
group of conclusions split into explicit / deductive / inductive
columns, with click-to-expand premise trees.
What's here:
- `lib/dreams.ts`: pure helpers. `clusterConclusionsIntoDreams` groups a
raw conclusions list into per-pair bursts using a configurable time
window (default 60s). `expandPremiseTree` walks `reasoning_tree` first
and falls back to a flat `premises` ID list, with cycle detection and
a depth cap. Defines an `ExtendedConclusion` type that augments the
generated schema with `conclusion_type`, `premises`, and
`reasoning_tree` — Honcho's migration f1a2b3c4d5e6 added those
columns but `schema.d.ts` doesn't expose them yet, so the UI degrades
gracefully (unknown types fall into "explicit").
- `api/queries.ts`: new `useDreams` hook that paginates the conclusions
list endpoint up to a configurable cap (default 400) and hands the
raw list to the UI for clustering. New `dreams` query key.
- `components/dreams/`:
- `DreamList.tsx` — route entry. Shows recent dreams as rows with
timestamp, observer→observed pair, and per-type counts. Selecting
a row expands an inline detail panel above the list.
- `DreamDetail.tsx` — three-column view (explicit / deductive /
inductive). Each inductive conclusion has a "Show premises" button
that expands the reasoning chain.
- `PremiseTree.tsx` — recursive premise renderer with type badges,
cycle indicator, and graceful handling of premises that fall
outside the loaded page.
- Routing: `routes/workspaces_.$workspaceId_.dreams.tsx` registers the
page; routeTree.gen.ts regenerated.
- Sidebar: new "Dreams" entry between Conclusions and Webhooks
(MoonStar icon to distinguish from the dark-mode Moon).
- Breadcrumb: "dreams" added to SECTION_LABELS so the trail resolves.
Tests (vitest, 14 new):
- clustering: empty input; same-pair burst within window; gap exceeds
threshold → split; different pairs don't merge even with overlapping
timestamps; custom gap window; newest-first ordering; counts default
unknown types to explicit.
- premise tree: empty children for no premises; flat list → direct
children; multi-level reasoning_tree recursion; missing premise
flagged (not in loaded page); cycle detection halts recursion;
maxDepth cap; reasoning_tree preferred over flat premises.
Verified manually in the preview: route mounts, sidebar/breadcrumb
resolve, error path renders cleanly, typecheck + lint + dream tests
all clean. The unrelated `app.test.tsx` failure is pre-existing on
main.
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>
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.
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.
