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

rev 732026-05-01

Closure-receipt outbound events + chronic-ack listing endpoint close the chronic-ack loop

Three new closure-receipt outbound events (`tag.chronic_warning_acked`, `source.chronic_warning_acked`, `assignee.chronic_warning_acked`)Closes the named rev-72 next-sprint candidate ("closure-receipt outbound events for chronic-ack"). Until rev 73, downstream integrations watching the rev-64 `assignee.chronic_warning` and rev-70 `tag.chronic_warning` outbound events had no closure signal — they'd see 'chronic alarm fired' but never 'chronic alarm acknowledged.' A FinOps tool tracking AI cost on a per-workstream dashboard, a manager dashboard listening to per-recipient chronic warnings, or a project tracker grouped by initiative had to either poll the dashboard for the current ack state or accept stale alarms. Rev 73 closes the loop. New `dispatchTagChronicWarningAckedWebhook`, `dispatchSourceChronicWarningAckedWebhook`, `dispatchAssigneeChronicWarningAckedWebhook` dispatchers wired into the matching `acknowledgeTagChronicWarning` / `acknowledgeSourceChronicWarning` / `acknowledgeAssigneeChronicWarning` helpers via `void dispatch...({...})` fire-and-forget so a downstream failure can't block the ack itself. Mirrors the rev-37 closure-receipt pattern (`task.unblocked`) + rev-61 task/source cost-spike-acked + rev-63 assignee.cost_spike_acked + rev-68 tag.cost_spike_acked at the *chronic horizon* (7d mute) rather than the *daily horizon* (per-day mute). **Strategic significance**: every rev-73 change makes an *existing* primitive load-bearing in a new place — the rev-64 + rev-70 chronic-warning outbound events now have closure receipts; the rev-71/72 chronic-ack write surface now reaches downstream integrations not just the dashboard.
`GET /api/v1/cost/chronic-acks` listing endpointCloses the named rev-72 follow-up at the read surface. New `listChronicAcks()` helper aggregates the three chronic-ack stamp surfaces — `workspace.tagChronicAcks` JSONB (per-tag), `source.chronicAckedAt` timestamp (per-source), `workspace_member.chronicAckedAt` timestamp (per-assignee) — and returns only the acks within the rev-71 7-day TTL. Stale stamps are excluded since they no longer suppress the chronic surface. Each row carries the ack timestamp + the expiry timestamp + a humanised handle so MCP hosts can render 'currently muted: #q3-launch (5d left), Steve's queue (3d left), RSS bridge X (6d left)' without follow-up calls per axis. **Strategic significance**: closes the rev-72 named follow-up at the read surface. Pairs with the rev-71 v1 chronic-spike read endpoints + rev-71/72 v1 chronic-ack write endpoints + the new rev-73 closure-receipt outbound events for the complete read/write/closure picture on the chronic surface. The cost-axis MCP cluster's chronic surface is now functionally complete — the upcoming MCP server's chronic-ack tooling has nothing left to design across read, write, or closure.
Outbound subscription picker grouped by category — exposes 26+ events across six groupsUntil rev 73 the `OutboundSubscriptions` picker only exposed the rev-18 four event types (`artifact.ready`, `artifact.approved`, `signal.created`, `task.assigned`) — operators couldn't subscribe to the cost-spike alarm cluster, the chronic-warning push surface, or the rev-73 chronic-ack closure receipts without writing a manual API call against the v1 surface. Rev 73 expands the picker to 26 events grouped into six categories: outputs & memory, signals & tasks, daily cost alarms, cost-alarm closure receipts, chronic warnings, chronic-ack closure receipts. Each group renders with a category header + hint inside a soft-bordered fieldset (`.ld-outbound-event-group` CSS) so the surface stays scannable as the event count grows. **Strategic significance**: closes a year-long ergonomics gap that had been silently growing since rev 18. The rev-19 per-event subscription primitive was load-bearing but the picker UI capped what operators could discover; rev 73 brings the dashboard surface to parity with the v1 surface.
Success-flash visual feedback on every chronic-ack chipUntil rev 73, clicking a chronic-ack chip kicked off a fetch + router.refresh and the chip simply disappeared on the next render — visually identical to a slow-network click that hadn't completed yet. Operators couldn't tell their counter-action took effect. Rev 73 adds a 480ms success state: on success, the chip switches to a brand-green `is-success` modifier (`@keyframes ld-chronic-ack-success`) showing `✓ Muted 7d` with a soft scale-up + box-shadow pulse before `router.refresh()` swaps the chip into its rev-72 muted/acked state. Applies to all three chronic-ack chips (per-tag rev-71, per-source rev-72, per-assignee rev-72). **Strategic significance**: cumulative micro-polish — every rev 22+ has carried at least one — but rev 73's polish is load-bearing because the chronic-ack surface is the operator's primary defensive lever on the rev-71/72/73 chronic-axis cluster, and the click → silent-disappear transition was the largest UX friction point left on the surface.