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 187 — Loop Desk changelog

rev 1872026-05-08Accelerating

Closes the named rev-186 next-sprint candidate (per-week trend mini-sparkline beside the rev-186 peak-week stat card on /changelog/cadence) so a procurement reviewer scanning the page reads the peak in context against adjacent weeks (peak vs prior 4 weeks, latest bar in brand-accent so the eye reads 'this is the peak') + closes a real bug in the rev-186 peak-week detail block (the public HTML page collected peak-week revs from `day.sampleRevs` which is capped at 5 per day, silently dropping revs from any 6+ rev day in the peak window — rev 187 reads from the full releases array the way the v1 endpoint already does so the public surface and the protocol-bound surface never drift) + opens the runners-up axis on the v1 cadence response with a `topWeeks[]` ranked array (top-3 most-active 7-day windows sorted desc by revCount with weekStart tiebreaker) so MCP hosts rendering 'most-active shipping weeks ranked' tables need only one bearer-less GET (no client-side re-bucketing of weeklyCadence by count) + opens the convenience axis on the v1 peak-week primitive with a new `GET /api/v1/changelog/peak-week?days=N` endpoint mirroring the rev-175 /changelog/latest convenience pattern at the peak-week axis so callers polling for 'what was Loop Desk's busiest shipping week?' no longer fetch the full /changelog/cadence response and walk weeklyBuckets client-side — the OpenAPI 3.1 spec types the new endpoint + the new topWeeks field with full schemas in lockstep — the cadence pattern from rev 78 onward (every dashboard primitive gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 97th unbroken rev — 109th unbroken cadence rev (rev 187)

Peak-week mini-sparkline anchors the rev-186 stat card on trajectory shape — closes the named rev-186 next-sprint candidateUntil rev 187 the rev-186 peak-week stat card on /changelog/cadence reported the static peak count + date range, but the trajectory shape — 'how does the peak compare to adjacent weeks?' — required scrolling to the rev-182 4-week trend chip beside it and mentally cross-referencing. Rev 187 closes that with a 4-bar inline mini-sparkline below the meta line on the peak-week stat card itself: trailing 4 weeks ending at the peak (or fewer if the peak sits too close to the start of the trailing window), latest bar (the peak week itself) wears the brand accent + slight outer glow so the eye reads 'this is the peak' before parsing surrounding weeks. Hidden when fewer than 2 weeks of data exist (a single-bar sparkline reads as broken). Pure derived state from the existing weekTotals aggregate — no extra round-trip, no schema cost. Strategic significance: closes the named rev-186 next-sprint candidate. Pairs with the rev-186 stat card (cumulative count + date range) + the rev-186 click-through anchor + the rev-186 peak-week detail block as the four-level reading horizon on the peak-week primitive: cumulative count → trajectory shape (rev 187 sparkline) → context (date range) → drill-down (rev-186 detail block).
Bug fix: peak-week detail block no longer drops revs from 6+ rev daysUntil rev 187 the rev-186 peak-week detail block on /changelog/cadence collected `peakWeek.revs` from each day's `sampleRevs` array — but `sampleRevs` was capped at 5 entries per day (the rev-178 v1 endpoint's intentional sample slice for compact JSON renders). Any day in the peak week with 6+ revs silently dropped revs from the public detail block. The v1 endpoint already filtered from the full releases array so the protocol-bound surface was correct; rev 187 fixes the public HTML surface to match. Now reads `releasesByDate.get(date)` directly so every rev shipped in the peak week's 7-day window surfaces in the per-rev detail list. Strategic significance: load-bearing for procurement reviewers comparing visible velocity — until rev 187 a 9-rev peak day shipped 5 visible revs in the detail block, which would have read as 'rev 187 lost 4 revs' on a careful read. Closes a small but real correctness gap in the same cycle the rev-186 stat card primitive lands.
topWeeks[] ranked array on GET /api/v1/changelog/cadence — closes the runners-up axis on the v1 peak-week primitiveDistinct from the rev-181 `peakWeek` primitive (single — the loudest week) by giving 'runners-up' context: a procurement reviewer comparing this quarter's shipping cadence sees not just 'the busiest week was 9 revs' but 'the top 3 weeks were 9 / 8 / 6 revs' — a richer trajectory signal. Top-3 sorted desc by revCount with weekStart tiebreaker for deterministic ordering when two weeks tie. Pure derived state from the existing weeklyBuckets aggregate (no client-side re-bucketing required, no extra cost on the response). Empty when no week in the window has any revs (fresh-window guard). The OpenAPI 3.1 spec types the new field with full schema in lockstep — the cadence pattern from rev 78 onward (every dashboard primitive gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 97th unbroken rev with rev 187. Strategic significance: pairs with the rev-186 peakWeekRevs[] projection (the actual rev list for the loudest week) so MCP hosts rendering 'most-active shipping weeks ranked' tables read both axes (which weeks ranked + which revs landed in the loudest one) without follow-up calls.
GET /api/v1/changelog/peak-week — convenience endpoint mirroring the rev-175 /latest pattern at the peak-week axisUntil rev 187 MCP hosts polling for 'what was Loop Desk's busiest shipping week?' had to fetch the full /api/v1/changelog/cadence response and walk weeklyBuckets client-side. Rev 187 makes the answer a one-call bearer-less GET. Returns the same `peakWeek` (start + end + count) + `peakWeekRevs[]` shape as the rev-178/186 cadence endpoint's peakWeek/peakWeekRevs fields, but without the per-day cadence array — pure peak-week answer for MCP hosts that don't need the high-resolution shape. Mirrors the rev-175 /changelog/latest convenience pattern at the peak-week axis. Optional `?days=N` query param (1-365, default 90) bounds the window the same way /api/v1/changelog/cadence does so the two endpoints never drift on what 'trailing N days' means at the same instant. Cache-control public, max-age=300, s-maxage=1800. Indexed in the /api/v1 self-describing endpoint list. Strategic significance: closes the convenience axis on the v1 peak-week primitive. The v1 changelog read surface is now five axes deep (listing rev 100/101 + per-rev detail rev 174 + latest rev 175 + cadence rev 178 + peak-week rev 187) — the MCP server's changelog-read tooling has nothing left to design.