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

rev 1432026-05-06

Bulk per-source poll-cadence override closes the named rev-142 next-sprint candidate at the cadence axis (POST /api/sources/bulk-cadence + v1 mirror in lockstep + GET /api/v1/sources projection extended with rev-142 pollGating shape inline + dashboard bulk-cadence chip + OpenAPI typed coverage on the new endpoint and the new field shape — 65th unbroken cadence rev)

Bulk per-source poll-cadence override (POST /api/sources/bulk-cadence + v1 mirror) — closes the named rev-142 next-sprint candidateOperators with 20+ rss.app/fetchrss bridge feeds who wanted to throttle a whole class of feeds (every LinkedIn bridge to daily) had to tap each source's cadence chip individually after rev 141 shipped the per-source override. Rev 143 collapses that to one operation. New `bulkSetSourcePollIntervals()` helper validates 1-1440 minutes (or null to clear the override) + the per-batch 50-source cap exactly mirroring the rev-36 + rev-96 source-bulk pattern. Operates workspace-wide (omit sourceIds — every pollable source picks up the new cadence) or scoped to an explicit subset. Manual / file-based sources are skipped silently (the rev-141 cadence axis only applies to feed-style sources rss / review_site / linkedin that the rev-5 RSS poller actually gates). Activity log records every per-source change + a single bulk summary line. Pairs with PATCH `/api/sources/{id}` (rev 141 single-source) + GET `/api/v1/sources/cadence-overview` (rev 142 read-aggregate) as the third primitive on the per-source cadence cluster (write-single rev 141 / read-aggregate rev 142 / write-bulk rev 143).
GET /api/v1/sources projection extended with the rev-142 pollGating shape inlineUntil rev 143 an MCP host driving the desk could read each source's `pollIntervalMinutes` column on the existing rev-141 GET projection but had to either fetch `/sources/cadence-overview` separately or compute the next-poll-at + due-now answer client-side. Rev 143 makes the answer load-bearing inline on every per-source row of GET `/api/v1/sources` — every row gets `pollGating: { sourceId, intervalMinutes, isOverride, lastSyncedAt, nextPollAt, isDueNow, minutesUntilDue } | null` matching the rev-142 cadence-overview perSource shape exactly. Manual / file-based / paused sources read `pollGating: null` since the rev-141 cadence axis only applies to active feed-style sources. Pure derived state from the existing rev-141 column + workspace cadence — no new persistence. MCP hosts rendering 'feed X is due to poll in 3 minutes' alongside other source metadata don't need the follow-up call to /sources/cadence-overview.
Dashboard SourceBulkCadence component + brand-purple palette distinct from the rev-96 brand-teal bulk-renameNew `SourceBulkCadence` client component mounts inside the rev-36 SourceBulkActions section + rev-96 bulk-rename block (sources panel footer) when 2+ pollable feed-style sources exist. Six presets (15m / 30m / 1h / 4h / 1d / Workspace cadence) match the rev-141 inline cadence chip vocabulary so operators pattern-match instead of re-reading the chip cluster from scratch. 'Workspace cadence' clears the per-source override (revert to rev-140 cadence). Apply asks for confirm via the cadence preset label so the operator can verify intent before the irreversible-feeling button. New `.ld-source-bulk-cadence*` CSS uses a brand-purple palette (`rgba(107,78,214,*)`) distinct from the rev-96 brand-teal bulk-rename + rev-141 brand-teal per-source cadence chip so operators tell at a glance which axis they're acting on. Two bulk surfaces stack as siblings inside the sources panel footer — one consistent visual vocabulary at the layout layer (panel + grid + animation) and distinct colour vocabularies at the action layer (rename axis = teal; cadence axis = purple). Cumulative micro-polish — every rev 22+ has carried at least one — and rev 143's polish is load-bearing because the rev-141 + rev-142 + rev-143 cadence cluster needed visual distinction from the rev-95 + rev-96 rename cluster on the same panel footer.
OpenAPI 3.1 typed coverage on POST /sources/bulk-cadence + extended GET /sources pollGating projection — 65th unbroken cadence revOpenAPI spec types the new POST `/sources/bulk-cadence` endpoint with full request/response schemas (pollIntervalMinutes nullable int 1-1440 + optional sourceIds[≤50] + ok/matched/updated/skipped response shape). The existing GET `/sources` schema picks up the new `pollGating` field shape inline alongside the rev-141 `pollIntervalMinutes` projection. The cadence pattern from rev 78 onward (every v1 enhancement gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 65th unbroken rev with rev 143. The OpenAPI spec changelog header gains a rev-143 block explaining the bulk-cadence axis closure. The `/api/v1` self-describing endpoint index also documents the new endpoint inline so MCP-host integrators reading the index discover it without opening the spec.