Loops & Tasks

Loops Task Workspace

A resumable Task Session where the breakdown emerges from talking the task through — Mallory maintains it, you don't manage a checklist around him.

Dated 2026-06-15Programme Loops & Tasks

Situation

Loops today are a clean checklist — a thread holds loop_items you tick off — but there's no help at the moment that matters most: when you actually sit down to do a task. The new primitive is the Task Session: a persistent, resumable workspace bound to one loop_item, holding a conversation, a breakdown, linked research, and state.

This yields a three-level hierarchy — Loop → Task → Steps — where steps are owned by the session, not promoted into nested loop_items. The breakdown is emergent and conversational: Mallory auto-creates and verbally completes steps as you talk, with light "added: …"/"ticked: …" reflections so the list never silently drifts from what you meant; a manual tap-to-edit fallback remains available.

Key decisions

Steps live in the session, not the loop

session_steps are a working artifact of this dialogue; the existing flat loop checklist stays untouched.

Breakdown is emergent, not managed

Mallory maintains steps from natural speech (auto-create + verbal completion) with brief reflections; manual add/check/reorder is a fallback, not the default.

Conversation stays in the shared message store

A nullable task_session_id on messages keeps sessions FTS-recallable and reuses existing summarisation for long sessions.

Unified archive-and-reopen gesture

Loops, task sessions, and digs share one tap-to-reopen model; only loops and sessions get 3-day-inactivity auto-close — digs get completed-decay instead, since a dig is one-shot.

R&D-readiness pinned now, cheaply

The session object already exposes title/loop/progress/status/resume_summary so the future R&D surface (a derived read view) needs no rework later.

Layout A — conversation-dominant

The conversation fills the screen (voice-first, TTS-flattened, auto-listen, barge-in) with a slim collapsible live-steps strip and inline research/recap cards.

Architecture

All session state lives in edge D1, running like any chat turn — no hot-path dependency on the Hub/Tower.

task_sessions (new)

id, loop_item_id, thread_id, status (active/parked/done), resume_summary, activity timestamps.

session_steps (new)

id, task_session_id, content, done, sort_order — the emergent breakdown.

messages.task_session_id

Nullable FK scoping the session's chat into the single, FTS-recallable message store.

investigations.task_session_id

Nullable FK linking a spawned dig back to its originating session for the workspace to render.

Step-maintenance extraction

Best-effort background pass (mirrors runThreadExtraction) that creates/closes steps and emits reflections; never blocks the turn on failure.

TaskWorkspace UI (Layout A)

Conversation-dominant screen with a slim live-steps strip, inline research cards, and the resume recap.

Risks & guardrails

Vault writes are not instant

"Save to vault" is captured instantly at the edge but persisted via the Hub's sync cycle, eventually — a conscious trade, not a bug.

Ambiguous task resolution

Chat drop-in ("let's work on X") fuzzy-matches against loop_items and must ask rather than silently pick the wrong task.

Best-effort extraction can miss

A failed step-extraction pass must never block the turn, but a missed "done that" needs the manual fallback to stay trivially correctable.

Lifecycle timing complexity

Auto-close-on-inactivity applies only to loops/sessions while digs get decay-of-completed instead — three related but distinct timers to keep consistent.

Delivery

Phase 1 — Loop lifecycle

Standalone quick-win: migration for explicit archive lifecycle, shouldAutoClose, auto-close cron, manual close/reopen route + web archive UI.

Phase 2 — Task Session data + CRUD

Migration for sessions + steps + foreign tags, pure lifecycle helpers, session/step routes.

Phase 3 — The working dialogue

Session-scoped messages/grounding, session-scoped chat turn, auto-maintained breakdown extraction, dig-from-session linkage.

Phase 4 — Web workspace UI

Session API client/state, reusable MessageView, TaskWorkspace (Layout A), entry points + in-motion state.

Phase 5 — Verification

Full sweep, browser/device verification, and an explicit operator-requested design-consistency review before ship.

Out of scope

Actionable steps / acting-in-the-world (a step becoming a gated action)Hermes delegation of heavy stepsThe full R&D surface itself (this session model is designed to converge with it later)Proactive-resume nudges and a task timerExplicit per-task hats (session uses the current hat only)

spec · docs/superpowers/specs/2026-06-15-loops-task-workspace-design.md
plan · docs/superpowers/plans/2026-06-15-loops-task-workspace.md

Mallory · Estate briefing