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

rev 1062026-05-02

Per-author profiles (bio + avatar) + table of contents on long posts + sitemap author/category pages + v1 related-posts endpoint

Per-author profiles (bio + avatar URL via JSON registry)Closes the named rev-105 next-sprint candidate. New data/blog-authors.json profile registry keyed by slugifyAuthor() so adding a real human byline only needs (a) the post frontmatter and (b) a new entry in the registry — no schema migration. Surfaces on the rev-105 per-author archive hero (avatar image + tagline + bio + outbound links) and the post-detail byline (avatar image when registered, gracefully degrading to the rev-105 initials treatment otherwise). Mirrored on /api/v1/blog/authors and /api/v1/blog/by-author/{slug} via a new typed `profile` block (null when no profile registered) so MCP hosts rendering 'browse by byline' surface bio + avatar without a follow-up call. Pairs with rev-105 byline drill-down as the depth-axis on the byline surface.
Table of contents sidebar on /blog/[slug]Surfaces the rev-102 per-heading anchors as a navigable index. Until rev 106 long-form posts (the rev-10 governance-first essay + rev-42 MCP announcement post both 2,000+ words across 8+ sections) had no at-a-glance overview of the content — readers either scrolled the whole post or relied on the rev-104 reading-progress bar to gauge position. The TOC closes that gap: every <h2> and <h3> surfaces as a stickied chip-list on the right edge of the article, with active-section highlighting via IntersectionObserver so the reader sees where they are at a glance. Reads headings the SAME way the rev-102 BlogHeadingAnchors writes them — same slugify rules + same dup-suffix logic — so the TOC and the per-heading chip resolve to the same anchor id every time. Hidden below 1100px (the reading-progress bar covers narrower viewports) and below 4 headings (more visual noise than navigation value on short posts).
Sitemap.xml extends to per-author + per-category pagesUntil rev 106 only static pages + per-post detail pages were listed in /sitemap.xml — crawlers (and AI tooling discovery systems) had no signal that the rev-104 /blog/category/[key]/rss.xml and rev-105 /blog/author/[slug] surfaces existed at all. Rev 106 closes that gap by enumerating every author archive page + every per-category RSS endpoint. Per-author lastModified anchors to the author's latestDate so search engines see the freshness signal. SEO win that pairs with the rev-103 JSON-LD Article markup (machine-readable per-post) + rev-105 byline drill-down (machine-readable per-author) for the full crawler-discoverability story across all three axes.
GET /api/v1/blog/related/{slug}?limit=5Closes the fifth axis on the v1 blog cluster (listing + detail + categories + authors + related). Until rev 106 the rev-103 detail endpoint inlined related posts as a side payload but there was no standalone axis reachable by slug — MCP hosts rendering 'you might also like' widgets, AI tooling roundup newsletters generating per-post sidebars, and search clients building 'more like this' affordances had to fetch the full detail body or re-implement the rev-102 tag-overlap scoring client-side. Rev 106 makes it a one-call answer that also returns the source post identity + author profile avatar + a per-result `sharedTagCount` so callers rendering 'shared 3 tags' hints don't have to recompute. Returns 404 when the source slug is missing. Cache-control public, max-age=300, s-maxage=1800.