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

rev 892026-05-02

Inline gating banner + multi-recipient gating endpoint + dashboard simulated-date input

Inline gating banner on the dashboard view-preview HTML — closes the named rev-88 next-sprint candidateRev 88's running state explicitly named the inline gating banner as the rev-89 candidate. Rev 89 ships it. The dashboard `/api/digest/preview?format=html` GET response now leads with a small inline banner that surfaces the rev-88 gating outcome at a glance: brand-color check + 'Would send · would deliver to maria@example.com' or amber 🔇 + 'Muted · maria@example.com — blocked by weekend mute (Saturday) + quiet hours window 22:00→07:00'. Until rev 89 admins opening the View-preview tab had to inspect the JSON variant to verify the rev-80/81 gating decision. Rev 89 makes the answer the first thing the eye lands on. The banner uses the same colour vocabulary (brand-color = action, amber = muted) as the rev-32+ cost-spike + chronic banners so the visual story across alarm + gating surfaces stays consistent. **Strategic significance**: closes the named rev-88 next-sprint candidate. Pairs with the rev-86 send-test (real email send) + rev-87 view-preview (HTML render) + rev-88 simulated-date primitive (gating block in JSON) as the fourth instrument on the digest verification cluster — admins now see the gating outcome inline in the rendered tab without parsing JSON.
GET /api/v1/workspace/digest-recipients-gating + dashboard mirror — multi-recipient gating previewNew bearer-auth v1 endpoint mirrors the rev-88 single-recipient gating decision across every owner/admin recipient on the workspace in one call. Returns per-recipient `{ digestQuietWeekends, digestQuietHoursStart/End, digestPersonalSections, weekendMuted, quietHoursMuted, wouldSend }` plus a workspace-level rollup of `{ recipientCount, wouldSendCount, mutedCount }`. Optional `simulatedDate=ISO` (±60d) overrides the gating instant identically to the rev-88 view-preview surface. Pure read-only — no email sends, no activity-log writes, no dashboardPrefs mutations. Reuses the same `workspaceOwnerEmails()` projection + rev-15 timezone math + rev-80 weekend-mute + rev-81 quiet-hours gating the production cron applies, so the answer is identical to what the 13:15 UTC cron would compute at the same instant. Dashboard mirror at `GET /api/digest/recipients-gating` (admin-only) drives the new live 'Would send N/M' pill in the integrations panel. Typed in the OpenAPI 3.1 spec in the same cycle. **Strategic significance**: until rev 89 the rev-88 gating block answered the *single-recipient* question. The multi-recipient surface is what admins actually need on multi-operator desks ('this digest fires for half the team but not Maria — let me check her quiet-hours config') and it's the natural shape for the upcoming MCP server's 'show me who would receive the next digest' tooling.
Dashboard simulated-date input + live 'Would send N/M' pill in integrations panelNew `<input type="datetime-local">` next to the rev-88 View-preview button lets admins ask 'what will the digest gating decision look like next Saturday at 8pm?' directly from the dashboard without crafting URLs by hand. The input's value is plumbed into both the View-preview anchor's `href` (so opening the tab carries the simulated instant) AND the new live gating-summary fetch that re-renders a 'Would send N/M' pill on every change. Pill colour follows the rev-32+ vocabulary: brand-color when all recipients receive, amber when some are muted, deep-red when every recipient is muted at the simulated instant. AbortController prevents stale fetches from clobbering newer ones if the operator scrubs the input rapidly. **Strategic significance**: until rev 89 the rev-88 simulated-date primitive was protocol-bound only — admins on the dashboard had to construct the URL by hand. Rev 89 surfaces it as a first-class input. The live pill closes the loop: admins see the gating outcome continuously without opening a tab.
Visual polish — digest controls cluster reads as a unified rowCumulative micro-polish (every rev 22+ has carried at least one). New `.ld-digest-controls` flex-wrap CSS so the rev-36 Send-test, rev-88 View-preview, rev-89 simulated-date input, rev-89 gating pill, and the rev-2 on/off toggle all read as a unified controls row that wraps cleanly on narrow viewports. The `<input type="datetime-local">` picks up the Loop Desk surface typography via `.ld-digest-simulated` (Loop Desk border + radius + focus ring) so it reads as a sibling of the surrounding buttons rather than a stamped-on browser-default control. The new `.ld-digest-gating-pill` shares the rev-21+ pill colour vocabulary with `is-clean` / `is-mixed` / `is-blocked` modifiers so admins read the gating outcome without parsing copy.