Roadmap: Open loops

The People roadmap in #534 calls for a reliable answer to two questions: who is waiting on me, and who am I waiting on? Open loops adds that conversation state to the archive, with the message that started the obligation, its age, and enough freshness evidence to know when the answer needs a refresh. This issue tracks the direction while the implementation stays split into focused pull requests.

Outcomes

• Track replies owed and replies awaited across email and chat without a model call. Start the clock at the oldest unanswered message and settle the turn at the first substantive reply.
• Show the same evidence-backed state through the CLI, HTTP API, MCP, and Directory person page, with person links and explicit coverage gaps.
• Let the owner mark a loop done, snooze it, or mute a conversation or sender. Preserve those decisions through incremental updates, identity changes, source merges, and rebuilds.
• Report both source freshness and projection progress. Refuse stale waiting rankings by default, with an explicit override for inspection.
• Let a loop be tracked in Kata without duplicate filing, and expose its linked issue and lifecycle signals from the conversation and person views.
• Extend the same loop model with cited commitments owed by me and owed to me, optional agenda suggestions, and optional reply-expectation scoring.

Delivery sequence

The ten core PRs below are implemented and open for review; they are not yet merged. Merge them in numbered order. The issue-linking follow-up is separate from that ten-part series.

1. Retain MIME automation evidence, unsubscribe-header presence, and calendar-part signals for downstream consumers (#1305).
2. Detect unanswered conversation turns, preserve the oldest anchor across nudges and acknowledgments, and handle quoted text and incomplete evidence (#1308).
3. Persist loop history, owner suppressions, derivation progress, revisioned invalidation, and MIME evidence with matching SQLite and PostgreSQL behavior (#1309).
4. Reconcile changed conversations transactionally, retain owner decisions, and preserve loop state across source merges and corrected metadata (#1310).
5. Report source and projection freshness, including configured accounts that have never synced and refresh commands for stale sources (#1311).
6. Derive loops in bounded background passes with resumable cursors, identity rescans, and MIME backfill (#1312).
7. Expose owner loop views, evidence, actions, scheduled derivation, and stale-ranking refusal through the daemon and HTTP API (#1313).
8. Add CLI waiting, list, detail, status, run, completion, snooze, mute, and unmute commands (#1314).
9. Expose MCP reads and confirmed owner actions behind explicit write opt-in (#1315).
10. Show a read-only Open loops card with evidence and freshness on the Directory person page, and document the feature (#1316).
11. Add opt-in tracking in Kata, saved issue links across loop views, and a bounded lifecycle bridge. This follow-up is open and stacked on #1316 (#1357).

Remaining follow-ups have no published PR linked here yet:

• Optional, default-off reply-expectation scoring with explicit provider consent, bounded background work, explainable suppression, and owner overrides. Missing or failed judgments leave the deterministic rules in charge; reads never call the provider.
• Commitment extraction through the people sweep, with exact cited evidence, due dates where stated, fact-ledger claims, and optional agenda suggestions through the shared issue-linking path. Suggested fulfilment requires owner confirmation unless automatic fulfilment is explicitly enabled. Fact freshness uses kind-specific windows, not a new numeric confidence score.

Design constraints

• The core is archive-derived and deterministic. It does not change provider read state or Inbox markers, and meeting action items remain a separate model.
• List, bulk, automated, and CC-only mail must not manufacture personal reply obligations. Acknowledgments, quoted questions, and missing evidence must not silently reset an obligation's clock or falsely settle it.
• Default grace periods are 24 hours for replies owed and 72 hours for replies awaited. The age belongs to the unanswered turn, not the latest nudge.
• Derived rows are rebuildable; owner decisions and retained history survive rebuilding. Incremental queues and bounded body reads avoid request-time full-archive scans.
• SQLite and PostgreSQL remain behaviorally equivalent. Schema upgrades and embedded-reader requirements are documented with the storage change.
• Freshness includes configured sources, sync outcomes, pending derivation, and coverage gaps. A recent job run alone does not certify the answer.
• Loop surfaces are owner-only in the initial series. MCP writes require explicit enablement and per-call confirmation; the initial Directory card is read-only.
• Issue tracking is opt-in. The bridge may comment on a linked Kata issue and read its status, but never changes that issue's state. Owner loop actions win.
• Public fixtures and examples use synthetic identities. Provider-backed follow-ups require consent and bounded disclosure and cost.

Adjacent

• #534: the broader People, relationships, activity, and CardDAV roadmap.
• #1330 and #1331: meeting prep consumes person context and open loops; it does not own their derivation.
• #1226: Inbox work uses provider observations and remains independent of archive-derived loops.
• #1172: native MCP Events; a loop-opened event is a later integration, not part of the initial loop series.