Loop Desk is an always-on business workspace that takes incoming signal (email, forms, feeds, notes) and turns it into briefs, watch items, and next actions.

Does Loop Desk send emails on my behalf?

Loop Desk can draft responses, but nothing sends until you approve and explicitly trigger it. The approval boundary is fundamental.

What signal sources does Loop Desk support?

Email, RSS/Atom feeds, form submissions, manual notes, and webhooks. The desk treats all sources equally in its processing loop.

rev 132 — Loop Desk changelog

rev 1322026-05-06

Per-thread search matchedIds on the v1/MCP surface + dashboard endpoint mirror with q + authorId query params + OpenAPI typed coverage + inline ↑↓ button affordances on the match counter chip

matchedIds on the v1 GET /tasks/{id}/comments?q= response — closes the named rev-131 next-sprint candidateRev 131 shipped the dashboard match counter chip + ↑↓ arrow-key navigation over per-thread search matches; until rev 132 a host driving the desk programmatically had to re-run the rev-128 matcher (body + author name, case-insensitive substring) against every comment to derive the same set. Rev 132 closes that gap by projecting matchedIds (ordered list of comment ids whose body OR author name contains the query) on the v1 comments GET response so MCP hosts rendering 'Steve's comments matching concern · 3 of 8' can use matchedIds.length as the total + rotate by index. Distinct from filtered (which counts matched-or-attached-to-matched entries — replies of a matched parent surface in the rendered thread but aren't themselves matches). Mirrors the rev-131 dashboard derivation exactly.
Dashboard /api/tasks/{id}/comments mirror with q + authorId + matchedIds — close dashboard-side parity gapThe rev-128 dashboard component computes filtering + matchedIds purely client-side; the dashboard endpoint had been GET-only with no query params for 106 revs. Rev 132 closes the dashboard-side parity gap so any direct caller of either surface (the v1 bearer-auth endpoint or the dashboard session-auth endpoint) reads one consistent shape — same q + authorId query params, same total/filtered/matchedIds/query/authorId response fields. The in-app TaskComments component still derives matchedIds client-side; the server-side path is load-bearing for direct integrations that hit the dashboard endpoint with the same workspace member session.
OpenAPI 3.1 typed coverage for matchedIds — cadence pattern from rev 78 onward holds unbrokenmatchedIds is typed inline on the comments GET endpoint as an array of strings with full description explaining the relationship to filtered (matched-or-attached) and the rev-131 N/M counter chip + arrow-key navigation primitive it powers. Required field on the response shape so MCP-host code generators always project it. The rev-78 cadence pattern (every v1 enhancement gets typed in the OpenAPI spec in the same cycle it ships) reaches its 55th unbroken rev with rev 132.
Cumulative dashboard polish — inline ↑↓ button affordances on the rev-131 match counter chipCumulative micro-polish (every rev 22+ has carried at least one). The rev-131 match counter chip surfaces N/M + a tooltip explaining the keyboard shortcuts, but mouse-first operators who don't hover for the tooltip never discover the rev-131 keyboard navigation primitive. Rev 132 pairs the keyboard discovery with mouse affordance: a tiny ↑↓ button group renders inside the chip when 2+ matches exist, firing the same state transitions as the rev-131 ArrowUp/ArrowDown handler so the two input modalities stay symmetric. Buttons share the brand-color teal palette + tabular-num typography of the parent chip so the cluster reads as one composite control. preventDefault on mousedown keeps the search input focused so a click-then-type rotation works cleanly. focus-visible outline ring matches the rev-38 dashboard accessibility pattern.