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

rev 802026-05-02

Per-recipient weekend mute, workspace reactions summary, OpenAPI discussion + reactions + focus surface coverage

Per-recipient weekend-mute for the daily digest (closes the third axis of operator-respect)Multi-operator desks accumulate operators with different work rhythms. Some are heads-down on weekends; others want to disconnect. Until rev 80 the only digest controls were workspace-wide on/off (rev 5) and per-recipient personal-section opt-out (rev 79) — but neither covered the temporal axis. Rev 80 adds the third axis: `digestQuietWeekends` on `workspace_member.dashboardPrefs`. Default false (digest sends every day). When true, the cron skips THIS recipient on Saturday + Sunday in the workspace timezone — Mon-Fri delivery is unaffected. Persisted on the existing JSONB column (no schema migration). Activity log records exactly how many recipients were weekend-muted on a given day so admins can audit 'why didn't I get the digest yesterday?'. UI in the integrations panel directly under the rev-79 personal-sections toggle so all three digest controls (workspace on/off, personal-sections opt-out, weekend mute) read as siblings. **Strategic significance**: closes the operator-respect cluster on three orthogonal axes — workspace-level chat-channel quiet (rev 15 Slack quiet hours), per-recipient personal-section opt-out (rev 79), per-recipient weekend mute (rev 80). The per-recipient temporal axis is the most-requested ergonomic feature from operators with strong weekend boundaries.
Workspace reactions summary — third descriptive lens after rev-28 tag insights + rev-31 focus historyComments (rev 29), artifacts (rev 33), memory entries (rev 33), and signals (rev 34) have all carried the same `Record<emoji, userId[]>` reaction shape with the same five-emoji vocabulary (👍 / 👀 / 🎯 / ❤️ / 🚀) since rev 34. Until rev 80 every reaction was scoped to its single entity — operators could see which comment got 👍 but had no surface for 'what content is resonating across the workspace this week?'. Rev 80 closes that with one aggregate read: `getWorkspaceReactionsSummary()` sums every reaction (deduplicated per-user-per-emoji-per-entity) across the four reactable surfaces and returns per-emoji workspace-wide totals + top-N reacted entities with parent context. New `GET /api/v1/workspace/reactions-summary?topLimit=8` v1 endpoint + matching dashboard endpoint + new `ReactionsSummaryPanel` client component mounted as a sidebar panel below the rev-28 tag insights and rev-39 tag manager. Hidden when the workspace has no reactions yet. **Strategic significance**: pairs with rev-28 tag insights (descriptive: what tags is the team working on?) and rev-31 focus history (prescriptive: what themes does the team prioritise?) as the third descriptive lens — what content is the team reacting to? Pure derived state — no schema, no migration, no new persistence.
OpenAPI 3.1 spec expanded to the discussion + reactions + focus surface (closes the named rev-79 next-sprint candidate)Rev 78 shipped the OpenAPI 3.1 spec covering the load-bearing core (workspace, signals, artifacts, tasks, memory, search, today, stats). Rev 79 expanded coverage to the cost-axis cluster + chronic-ack endpoints + dashboard-prefs. Rev 79's running state explicitly named expanding to 'the rev-26 comments + rev-29 reactions + rev-30 mentions inbox endpoints' as the rev-80 candidate. Rev 80 closes that — the OpenAPI spec now types: `/tasks/{taskId}/comments` GET/POST (rev 26-28), `/tasks/{taskId}/comments/{commentId}/reaction` POST (rev 29), `/artifacts|memory|signals/{id}/reaction` POST (rev 33-34), `/workspace/focus-tags` GET/PUT (rev 29-30), `/workspace/focus-history` GET (rev 31), `/workspace/insights` GET (rev 28), the new `/workspace/reactions-summary` GET (rev 80), and the rev-80 `digestQuietWeekends` field on dashboard-prefs. **Strategic significance**: the discussion + reactions + focus cluster is the most operator-loaded surface on the desk that wasn't typed until rev 80. MCP hosts wrapping `/api/v1` for collaboration tooling (post a comment, react to an artifact, set focus tags from chat) now have typed contracts for every primitive. Coverage continues to grow rev-by-rev; the full self-describing index at `/api/v1` remains authoritative for the complete endpoint list.
Visual polish — reactions summary panel + cumulative micro-polishNew `.ld-reactions-summary-*` CSS uses the same brand-accent palette as the rev-28 tag-insights panel so the three descriptive panels (tag insights / tag manager / reactions summary) read as a coherent visual cluster. Per-emoji tally chips with hover lift; per-entity rows with kind-tinted left-border accents (purple for comments, brand-color for artifacts, amber for memory, teal for signals) so operators can scan reactions by entity-type at a glance. Click any row to jump to the matching panel. Cumulative micro-polish — every rev 22+ has carried one — and rev 80's polish is load-bearing because the new sidebar panel needed visual distinction without competing with the rev-28 + rev-31 panels above it.