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

rev 1392026-05-06

OCC primitive extended to the rev-136 density axis — closes the named rev-138 next-sprint candidate + Outpaced — reloaded chip on the rev-39 density toggle + v1 mirror in lockstep + OpenAPI typed coverage on the new field shape

Per-field OCC on the rev-136 density primitive — closes the named rev-138 next-sprint candidateUntil rev 139 the rev-136 multi-device sync of dashboard density was last-writer-wins. If Machine A toggled compact at T1 and Machine B toggled comfortable at T2 with T2 > T1 but Machine A's PUT arrived after Machine B's PUT (network reorder, slow connection, retry backoff), Machine A's *older* density clobbered Machine B's newer one. Rev 138's running state explicitly named 'OCC primitive extended to density' as the rev-139 candidate, citing that density was the last of the three multi-device-synced primitives on the rev-78 dashboardPrefs JSONB still operating as last-write-wins (taskCommentFilters got OCC at rev 136; costPanelOrder got OCC at rev 138). Rev 139 closes the OCC symmetry across all three: a single epoch-ms `densityUpdatedAt` companion field on the prefs payload. When the patch carries `densityUpdatedAt` older than the existing server-side stamp, the server keeps the newer density and surfaces the rejection on the rev-137 telemetry trail at `rejected.density: { reason: 'stale_write', existingAt, incomingAt } | null`. Density is a single field (not per-axis like costPanelOrder), so the rejection is a single object — present means rejected, null means accepted. Mirrors the rev-136 taskCommentFilters + rev-138 costPanelOrder OCC semantics exactly so the three multi-device-synced surfaces have one consistent conflict-resolution story.
Outpaced — reloaded chip on the rev-39 density toggle + canonical re-sync from responseDensityToggle client-side: every fire-and-forget PUT to `/api/workspace/dashboard-prefs` now reads the response. When the response carries `rejected.density`, the client (a) surfaces a brand-amber 'Outpaced — reloaded' chip beside the rev-136 'synced' ambient state chip, (b) re-syncs local state from the canonical `prefs.density` returned on the same response — no follow-up GET. Auto-fades after 5s; click to dismiss early. A suppression ref ensures the re-sync setState doesn't fire another PUT in a loop. Brand-amber palette (`rgba(207, 108, 58, *)`) mirrors the rev-137 per-thread filter Outpaced chip + rev-138 cost-panel-order Outpaced chip exactly so the dashboard's three multi-device-synced surfaces (taskCommentFilters rev 137 + costPanelOrder rev 138 + density rev 139) read with one consistent transient-confirmation visual story across three distinct attention levels: passive (Synced teal), passive (saved-on-device grey), transient (Outpaced amber). The intent timestamp is captured at the moment of toggle (not the moment of debounced send) so the OCC step compares against operator intent rather than network reorder timing.
v1 mirror + OpenAPI 3.1 typed coverage on the rev-139 OCC primitive — 62nd unbroken cadence revBearer-auth `/api/v1/workspace/dashboard-prefs` PUT accepts the new `densityUpdatedAt` field via the same Zod schema as the dashboard route, returns the same `{ prefs, rejected }` response shape extended with `rejected.density` so MCP hosts driving the desk programmatically across multiple machines (e.g. a watcher agent on a CRON server + a manual operator on a laptop) see exactly when the OCC step rejected the density write — they can avoid double-syncing the same density or skip a follow-up GET to re-fetch the canonical server state. The cadence pattern from rev 37 onward (every dashboard mutation has a v1 equivalent within one rev) holds unbroken into rev 139. OpenAPI spec types the new `densityUpdatedAt` integer field on the PUT request body + the new `rejected.density` object on the PUT response with full per-field shape (reason enum 'stale_write', existingAt + incomingAt timestamps). Pure spec additions — existing rev-138 callers reading only `rejected.taskCommentFilters` + `rejected.costPanelOrder` keep working since `rejected.density` is just a new sibling field.
Cumulative dashboard polish — brand-amber chip vocabulary anchored across all three OCC surfacesNew `.ld-density-outpaced` chip + `.ld-density-outpaced-dot` pulsing dot + `@keyframes ld-density-outpaced-fade` (5s) + `@keyframes ld-density-outpaced-pulse` (1.4s) + `:focus-visible` outline ring matching the rev-38 dashboard accessibility pattern. Brand-amber palette distinct from the rev-127 brand-color teal sync chip + rev-136 muted-grey local chip so the three transient-confirmation chips on the density toggle row read at three distinct attention levels. The rev-139 Outpaced chip closes the rev-22+ visual-hierarchy thread on the dashboard's three multi-device-synced surfaces — one consistent vocabulary across taskCommentFilters (rev 137), costPanelOrder (rev 138), and density (rev 139). Cumulative micro-polish (every rev 22+ has carried at least one) — rev 139's polish is load-bearing because it anchors the new transient-confirmation chip in the rev-22+ design language thread that has run since rev 22 and now spans the entire OCC cluster.