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

rev 1122026-05-03

Optional renew note feeds AI as direction + persistent template markdown preview + workspace-shared template usage counts + cumulative renew-button polish

Optional renew note + AI direction (closes named rev-111 candidate)Closes the named rev-111 next-sprint candidate at the renew axis. Until rev 112 the rev-50 renew flow was a one-tap 'I am still working on this' affordance — bumps updatedAt + clears the rev-50 archive warning stamp + writes an activity-log line, no operator → AI direction channel. Operators routinely renewed a stale task because they were waiting on a teammate's input or an external dependency, and the desk had no way to know that. Rev 112 adds an optional 600-char inline note. When provided, the renew also routes the note through the rev-14 addTaskOperatorNote() helper so it lands on task.operatorNotes JSONB and the next runAiTaskSession reads it under the OPERATOR NOTES (treat as authoritative) prompt block. Activity log entry is differentiated to 'Operator renewed task with operator direction' so the audit trail captures both lineage and intent. The chevron next to the existing renew button reveals the textarea inline; the one-tap path stays untouched. Mirrors the rev-111 regenerate-as-direction pattern at the renew axis exactly. The four operator → desk channels (rev 11 approve/regenerate, rev 14 operator notes, rev 21/22 priority/due, rev 23 inline body edit, rev 24 manual creation) plus the rev-111 enriched regenerate plus the rev-112 enriched renew now all read as one consistent steering vocabulary — every operator action that touches a task reaches the AI cycle via the same authoritative direction surface.
Markdown rendering on persistent task template goal preview (closes named rev-111 candidate)Closes the named rev-111 next-sprint candidate at the templates axis. Extends the rev-10 / rev-110 / rev-111 markdown rendering quartet to a fifth axis (the rev-66 persistent task template goal field). When an operator applies a saved template whose goal carries markdown structure (headings, lists, callouts), a brand-color-accented preview block renders above the form fields so the operator sees how the goal will render before queueing — closes the verification gap that until rev 112 only became visible after queueing the task and waiting for the AI cycle to consume it. Reuses the rev-111 shared shouldRenderAsMarkdown() heuristic so short one-line goals stay plain and only structured goals pay the marked.js round-trip. New .ld-task-create-template-preview typography pairs with the rev-110 memory-md + rev-111 operator-note + comment-md treatments so all five markdown surfaces (artifact bodies, memory entries, operator notes, task comments, persistent template goals) read as one visual family.
Workspace-shared usage count chip on persistent template chipsEvery persistent template chip (rev 66) now surfaces a quiet '· N×' workspace-shared usage count when usageCount > 0. Distinct from the rev-65 per-operator localStorage 'recent' badge — the rev-65 badge surfaces *this operator's* most-recent template; the rev-112 chip surfaces *the workspace's* historical popularity. The two reading horizons coexist on every chip without competing visually (recent = brand-color pill, usage = subtle teal counter). Multi-operator teams now see at a glance which saved templates are load-bearing across the workspace vs vestigial — foundation for pruning low-value templates. Pure read of the existing rev-66 usageCount column on the task_template table; no schema change.
Cumulative polish — split renew button + visual treatment for the new note shellCumulative micro-polish (every rev 22+ has carried at least one). The rev-50 amber-tinted renew button is now a two-part cluster: the primary 'Renew' button keeps the one-tap path unchanged + a chevron toggle reveals the rev-112 inline note shell. New .ld-task-renew-shell + .ld-task-renew-textarea + .ld-task-renew-submit + .ld-task-renew-cancel CSS uses the same brand-color amber→brand-color gradient as the rev-111 regenerate primary button so the two operator → AI direction surfaces (regenerate-with-note + renew-with-note) read as siblings with one consistent visual vocabulary. The textarea picks up the rev-111 :focus-visible outline ring so keyboard-only operators land cleanly. Closes the visual-hierarchy gap that would have grown as the rev-50 renew button accumulated more behavior.