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

rev 1842026-05-08Accelerating

Closes the named rev-183 next-sprint candidate (trajectory verb on the rev-180 ShippingCadencePill tooltip) at the load-bearing in-app axis — the rev-181 4-week trend numeric breakdown in the tooltip names the SHAPE; the rev-184 trajectory verb names what that shape MEANS so an operator hovering the pill answers 'is the cadence accelerating?' without scrolling to the rev-183 CadenceTrendChip beside the heartbeat indicator + opens a per-rev historical trajectory chip on every /changelog/[rev] detail page anchoring the rev as a data point on the cadence story rather than an isolated event ('shipped during an accelerating week') + closes the per-rev v1 parity gap in lockstep with a new historicalTrajectory field on the rev-174 GET /api/v1/changelog/{rev} response so MCP hosts inherit the same rev-as-cadence-data-point primitive on the protocol-bound surface + closes two more rev-183 named radar candidates at the templates axis (independent funeral homes with FTC Funeral Rule disclosure + named-family after-care + state-board licensing currency + pre-need contract integrity discipline + small marine / aviation services with named-platform records + FAA/USCG airworthiness/seaworthiness directive cadence + safety-incident reporting + insurance-currency discipline) — the templates cluster reaches forty-one named verticals — extracts a shared computeShippingTrajectoryAt() helper from changelog-releases.ts so the dashboard rev page chip + the v1 endpoint historicalTrajectory field both read from one canonical computation — 106th unbroken cadence rev (rev 184)

Trajectory verb on the rev-180 ShippingCadencePill tooltip — closes the named rev-183 next-sprint candidateUntil rev 184 the rev-180 dashboard ShippingCadencePill carried a 4-week numeric trend in its hover tooltip ('0 / 2 / 1 / 4') but not the trajectory verb — operators hovering the pill saw the SHAPE of the cadence but had to interpret it themselves to answer 'is this accelerating?'. The rev-183 CadenceTrendChip beside the rev-12 heartbeat indicator names the verb explicitly, but that's a second instrument an operator has to look at separately. Rev 184 closes that gap by extending the pill's tooltip with the rev-183 trajectory verb + delta-vs-prior-week ('Trajectory: Accelerating (+3 vs prior week)') so the same one-pill hover surfaces both the shape AND the meaning. Pure presentation extension on the existing tooltip — zero new client-state, zero schema cost. Reuses the rev-183 shared computeShippingTrajectory() helper threaded through from the dashboard server component so the pill tooltip + the rev-183 chip + the rev-182 /changelog/cadence verb chip never drift on what 'this week vs prior week' means. Plus aria-label extension so screen-reader users hear the same verb the sighted-user tooltip surfaces — until rev 184 the pill announced only the rev count, dropping the trajectory dimension entirely for assistive-tech users. Strategic significance: closes the named rev-183 candidate at zero cost. The two-instrument cadence cluster on the dashboard status bar (rev-180 ShippingCadencePill + rev-183 CadenceTrendChip) now both read at the verb axis without operators needing to look in two places.
Per-rev historical trajectory chip on /changelog/[rev] detail pagesUntil rev 184 the rev-169 per-rev /changelog/[rev] detail pages surfaced the rev's title + date + highlights + the rev-174 share affordance + the rev-175 BreadcrumbList markup, but read as isolated events — an external reader landing on a permalink share saw what the rev did but not where it sat in the cadence story. Rev 184 closes that with a small inline 'Accelerating' / 'Cooling' / 'Steady' chip in the per-rev meta row showing the trajectory state at the time the rev shipped (computed by walking the rev-37 release list anchored at the rev's shipping date with future revs excluded so the chip reflects what the cadence looked like at the moment, not with hindsight). Brand-green palette when accelerating + amber when cooling matches the rev-183 dashboard CadenceTrendChip palette so the in-app + public surface speak one trajectory vocabulary. Click-through opens the public /changelog/cadence calendar so an interested reader can see the broader cadence picture. Pure derived state — no schema cost. Strategic significance: anchors every per-rev share surface (procurement-team release-note shares, AI-tooling release-roundup newsletter citations, customer-success internal documentation links) on the cadence story rather than the rev alone. 'shipped during an accelerating week' reads as a stronger product-momentum signal than the rev's title in isolation, especially for procurement teams evaluating governance-first AI tools against per-cycle-credits competitors.
historicalTrajectory field on GET /api/v1/changelog/{rev}Mirrors the rev-184 dashboard per-rev chip on the protocol-bound surface in the same cycle the dashboard primitive ships (the cadence pattern from rev 37 onwards continues unbroken through rev 184). The rev-174 GET /api/v1/changelog/{rev} response gains a new historicalTrajectory block carrying the trajectory verb (label + latest + prior + delta + hasActivity) computed at the rev's shipping date so MCP hosts rendering 'show me where this rev sits on the cadence story' don't need to fetch /api/v1/changelog/cadence + bucket by-week + diff client-side. Pure additive on the existing rev-174 response shape — existing v1 callers reading only release / neighbors keep working since historicalTrajectory is a new sibling field. The OpenAPI 3.1 spec types the new field with full schema in lockstep — the cadence pattern from rev 78 onward (every dashboard primitive gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 94th unbroken rev with rev 184. Strategic significance: pairs with /api/v1/changelog/trend (rev 183 — current trajectory) + /api/v1/changelog/cadence (rev 178 — full per-day shape) + /api/v1/changelog/latest (rev 175 — convenience read) as the four-axis cadence read cluster on the protocol-bound side. The MCP server (Q3 #1) gains one more pre-typed surface with nothing left to design across the changelog-cadence cluster at any read shape including the per-rev historical axis.
Two more onboarding templates — Independent funeral homes + Small marine / aviation servicesCloses two more of the rev-183 named radar candidates at two more underserved verticals where regulated-disclosure + safety-cadence discipline is the load-bearing differentiator. Independent funeral homes (owner-led funeral homes + cremation providers — 4 high-importance memory entries: FTC Funeral Rule disclosure cadence with structured GPL/CPL/OBCPL handoff before any goods or services are quoted, named-family after-care cadence with structured 30-day + 90-day + 1-year touchpoints, state-board licensing currency with named CEU + renewal package tracking, pre-need contract integrity with named trust-account custodian + named state-disclosure-form acknowledgement + 1 sample 60-day after-care touchpoint feedback signal). Small marine / aviation services (owner-led marine + aviation maintenance, charter, and flight-training operators — 4 high-importance memory entries: named-platform records with named tail/hull number + named-mechanic-of-record + named cycle/hour count discipline, FAA airworthiness directive + USCG marine notice cadence with 14-day applicability review, safety-incident reporting discipline with NTSB / FAA Service Difficulty Report / USCG Form 2692 / MAIB filing windows, insurance-currency thresholds with named broker-of-record + 30-day renewal package gating + 1 sample emergency airworthiness directive signal). Two new OnboardingTemplateKey enum values (funeral_home, marine_aviation_service) extend the rev-19 enum without migration. The templates cluster is now forty-one named verticals deep — closes the day-1 starvation-point story across two more underserved owner-led segments where regulated discipline (FTC Funeral Rule + state-board funeral-director licensing + state pre-need contract custodian regulations on the funeral home side, FAA airworthiness directives + USCG / MAIB / EASA equivalents on the marine/aviation side) is the load-bearing differentiator against generic AI tools that don't know the regulatory vocabulary.