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

rev 942026-05-02

Per-task work-log share daily-views sparkline + per-task timeline share permalink + v1 + OpenAPI parity

Per-task work-log share 14-day daily-views sparkline — closes the named rev-93 next-sprint candidateRev 93 shipped the public per-task work-log share page + cumulative view counter, but no daily-views surface — the rev-13 artifact share already had a 14-day sparkline (rendered inline in the dashboard ArtifactShareButton), so engagement-tracking parity was the missing edge. Rev 94 closes it. New `task_work_log_share_view` per-day event table + extended `recordTaskWorkLogShareView()` writes both the cumulative counter and an event row + new `getTaskWorkLogShareDailyViews()` helper + new `GET /api/tasks/{id}/work-log-views` route + matching `GET /api/v1/tasks/{id}/work-log-views` v1 mirror. New ViewSparkline subcomponent inside the rev-93 TaskShareWorkLogButton lazily fetches the 14-day buckets when the share link is open and renders the same brand-color SVG sparkline as the rev-13 artifact share button. **Strategic significance**: closes the engagement-tracking parity gap explicitly named in the rev-93 next-sprint focus list. Operators iterating on procurement evidence now see whether a reviewer has been re-reading the work log over a week vs reading once and moving on — load-bearing context for following up on shared evidence.
Per-task timeline share permalink — closes the named rev-93 next-sprint candidateRev 93 shipped the work-log share (`/share/work-log/<token>`) covering AI cycle output + operator notes only; the rev-40 in-app TaskTimeline aggregates more (adds rev-26 comments + the creation event) so a richer 'everything that happened on this task' public read was the natural follow-up. Rev 94 closes it. New `task.publicTimelineToken` + `publicTimelineViewCount` + `publicTimelineLastViewedAt` columns + `setTaskTimelineShareToken()` + `getTaskByTimelineShareToken()` + `recordTaskTimelineShareView()` helpers + `POST /api/tasks/{id}/share-timeline` route + matching `POST /api/v1/tasks/{id}/share-timeline` v1 mirror. New public read-only `/share/timeline/[token]` page renders the rev-40 unified timeline (creation + AI cycles + operator notes + comments) with per-kind colour-tinted left-border accents (brand-color = AI cycle, amber = operator note, brand-purple = comment, green = creation) so an external reader scans the narrative by event type. Robots-noindex, fire-and-forget view counter, print-friendly via the rev-92 print stylesheet (extended in lockstep). New TaskShareTimelineButton mounts alongside the rev-93 TaskShareWorkLogButton on every active-work card so operators choose which surface to expose per task. **Strategic significance**: closes the named rev-93 next-sprint candidate. The procurement story across the public surface is now six levels deep: input evidence (rev 42) + revision lineage (rev 44) + interactive narrowing (rev 45/46) + take-and-print (rev 92) + AI cycle reasoning trail (rev 93) + complete task narrative (rev 94). Distinct from rev-93 work-log share so operators control the granularity of what they expose — narrow procurement evidence (rev 93) vs full collaboration narrative (rev 94).
v1 + OpenAPI typed-schema coverage on the new rev-94 endpointsBoth new dashboard primitives ship with v1 mirrors in the same cycle (the cadence pattern from rev 37 onward continues unbroken). New `POST /api/v1/tasks/{id}/share-timeline` + `GET /api/v1/tasks/{id}/work-log-views` endpoints + matching typed schemas in the OpenAPI 3.1 spec + entries in the `/api/v1` self-describing endpoint index. **Strategic significance**: closes the v1 parity gap on the rev-94 dashboard primitives in the same cycle the dashboard primitives ship. The MCP server's task-share tooling now has two parallel surfaces (work-log narrow + timeline broad) typed end-to-end with no protocol-translation work left to design.
Visual polish — timeline share page anchored in the rev-93 worklog vocabulary + per-kind tintsNew `.ld-share-timeline-*` CSS uses the same brand-green left-border + soft gradient as the rev-93 work-log share page so the two procurement-takeaway surfaces on `/share/*` read as siblings. Per-kind row tints distinguish AI cycles (brand-color), operator notes (amber `#cf6c3a`), comments (brand-purple `#6b4ed6`), creation events (green `#2c8a4a`), and activity-log entries (neutral) — same per-kind colour vocabulary as the rev-40 in-app TaskTimeline + rev-35 activity log glyph palette so the dashboard reads with one consistent kind-tinting language across all three surfaces. The rev-92 print stylesheet extended to cover the new timeline classes so the takeaway PDF reads cleanly. **Strategic significance**: keeps the rev-by-rev visual-hierarchy discipline alive — every share surface now carries the same chrome but distinguishes itself by accent palette, so the operator's eye reads the surface type without parsing copy.