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

rev 1362026-05-06

Server-side optimistic concurrency control on per-thread filter sync + dashboard density preference synced across devices + OpenAPI typed coverage in lockstep + Synced ambient state chip on the rev-39 density toggle

Server-side optimistic concurrency control on taskCommentFilters — closes the named rev-135 next-sprint candidateRev 135 closed the server-side multi-device sync of per-thread discussion filter scope but the partial-merge logic was last-write-wins. If Machine A wrote {q: 'concern', at: T1} and Machine B wrote {q: 'spike', 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* scope clobbered Machine B's newer one. Rev 135's running state explicitly named 'server-side conflict resolution for taskCommentFilters multi-device sync' as the rev-136 candidate, citing the optimistic-concurrency-control pattern that rev-78 panel collapse merge-by-union sidestepped. Rev 136 closes that gap. setDashboardPrefs's partial-merge logic now compares the incoming entry's `at` timestamp against the existing server-side entry's `at`; when the incoming write is older, the server keeps the newer one (last-writer-with-newer-timestamp wins). Equal timestamps fall through to the upsert path so a no-op refresh from the same device still works. The deletion path (empty scope) is exempt from the timestamp check because a clear-filter intent is always honoured — the alternative would leave operators unable to clear a filter on a power-user device that was offline. Mirrors the optimistic-concurrency-control pattern used by every modern sync surface (CRDTs, last-writer-wins-with-timestamp, etc.) at the cheapest possible primitive — no new schema, no new column, just a per-entry timestamp comparison inside the existing rev-135 partial-merge logic.
Dashboard density preference synced across devices — extends the rev-78 multi-device-sync pattern to its eleventh field familyNew optional `density` field ("compact" | "comfortable") on `DashboardPrefs`. Rev 39 shipped the dashboard density toggle as a localStorage-only primitive — an operator who set compact mode on Machine A still saw comfortable mode on Machine B. Multi-device operators on the procurement-conscious end of the customer base routinely complain about exactly this kind of friction. Rev 136 closes that gap. Same dual-layer sync pattern as rev-127 cost-panel order + rev-78 panel collapse: localStorage stays the immediate write-through cache for sync render so the dashboard never blocks on a network round-trip on first paint; server JSONB is the source of truth for cross-device drift; fire-and-forget debounced PUT (~300ms after the last toggle) keeps the network cost off the render hot path. The DensityToggle component prefers `serverInitialDensity` over localStorage on first render so cross-device drift wins (Machine A's most-recent toggle follows the operator to Machine B). Wired through three layers in lockstep: dashboard `/api/workspace/dashboard-prefs` Zod schema accepts the new enum; v1 `/api/v1/workspace/dashboard-prefs` bearer-auth mirror accepts it identically (the cadence pattern from rev 37 onwards continues unbroken); setDashboardPrefs clamps to the two allowed values, falling back to 'comfortable' on any other input. The DELETE reset-to-defaults path also clears the density preference. The rev-78 multi-device-sync pattern (collapsedPanels rev 78 / digestPersonalSections rev 79 / collapsedActivityBuckets rev 79 / digestQuietWeekends rev 80 / digestQuietHoursStart-End rev 81 / panelOrder rev 82 / activeWorkSort rev 83 / costPanelColumns rev 84 / costPanelOrder rev 127 / taskCommentFilters rev 135 / density rev 136) now reaches its eleventh field-family on the dashboardPrefs JSONB.
OpenAPI 3.1 typed coverage on the rev-136 density field + rev-136 OCC semantics in lockstep — 59th unbroken cadence revCloses the typed-contract gap on both rev-136 primitives in the same cycle they ship. The OpenAPI spec's `/workspace/dashboard-prefs` GET response shape + PUT request body gain a typed `density` field (enum ["compact", "comfortable"]) with the dual-layer sync pattern documented inline. The existing `taskCommentFilters` schema description picks up the rev-136 OCC behaviour: 'when the incoming write is older than the existing server-side entry, the server keeps the newer one' + 'the deletion path is exempt' + 'mirrors the OCC pattern used by every modern sync surface (CRDTs, LWW-with-timestamp).' The `at` field description also notes its dual role (LRU eviction + OCC). The rev-78 cadence pattern (every dashboardPrefs field gets typed in the OpenAPI spec in the same cycle it ships) reaches its 59th unbroken rev with rev 136. MCP-host code generators reading the spec see a typed contract for cross-device sync of dashboard density immediately, plus the OCC semantic on the rev-135 sync surface so a programmatic caller building a watcher agent that polls the prefs across multiple devices knows their write may be silently rejected if a newer one already landed.
Cumulative dashboard polish — Synced ambient state chip on the rev-39 density toggle + focus-visible accessibility ringTwo complementary visual affordances on the rev-39 density toggle. (a) New `.ld-density-sync` brand-color teal ambient state chip surfaces beside the toggle when the operator has chosen compact mode AND server prefs are reachable (i.e. the cross-device sync state is active). 'cursor: help' tooltip explains 'Saved to your account — this density follows you across devices' so the operator's eye lands on explicit confirmation that their preference is portable. Mirrors the rev-127 cost-panel-order sync chip vocabulary so the dashboard's three cross-device-sync surfaces (panel inventory + cost-panel ordering + density) read with one consistent visual story. (b) New `:focus-visible` brand-color outline ring on the density toggle button matches the rev-38 dashboard accessibility pattern so keyboard-only operators land cleanly. New `.ld-density-toggle-group` flex container wraps the button + chip cluster as a unified control surface. Cumulative micro-polish (every rev 22+ has carried at least one) — rev 136's polish is load-bearing because until rev 136 the density preference's cross-device portability would have happened invisibly to the operator; rev 136 makes it explicit + ambient + tooltipped without screaming.