Proposal: private named Summaries across selected conversations

# Proposal: private, named Summaries across selected conversations

Buzz has conversation history and agent execution, but catching up across several rooms still requires opening each transcript. I propose an optional Summary surface: choose an agent, explicitly select conversations, and receive a readable report on demand or on a local-time schedule. Each named Summary has its own progress and report history.

A working fork implementation now exists. I am opening this issue before proposing the upstream code so we can agree on the product and protocol boundaries and contribute focused changes rather than a fork-wide diff.

## Proposed experience

- A guided setup uses the existing agent selection/edit controls and the user's configured runtime/model defaults.
- Users explicitly select channels and DMs they may read. The agent receives a revocable, read-only grant for those sources, without joining a DM or gaining ordinary subscription/write rights.
- Named Summaries have independent cursors, manual execution, timezone-aware schedules, pause/archive controls, and immutable report history.
- Reports show their covered period and sources. Readers can search, open, copy, export, and archive them; owner-confirmed regeneration creates a new report for the historical interval without rewinding ordinary progress.
- Sharing is optional. A recipient must already be eligible to read every private source. New recipients do not gain older reports; removal revokes subsequent relay reads. A copied/exported report cannot be recalled.

The fork places the reader and guided setup behind the Pulse Summary experiment. Is Pulse the right home, or should the reader live elsewhere? Agent lifecycle/model administration should continue to use existing Agents controls rather than becoming a second management system.

## Protocol and authority

The roles are owner-signed definitions, per-Summary source progress, execution receipts, and immutable reporter-signed reports. The upstream kind allocation is **TBD**. The fork's legacy `30623`/`30624` overlap with #2704, and `30623` also overlaps with #6387; this proposal does not reserve those numbers or claim `40030` is allocated.

The implemented privacy model is authenticated relay access over plaintext, consistent with the current VISION.md model of TLS plus storage-layer encryption. It is not end-to-end encryption. The new authority requiring review is explicit owner delegation of reads, particularly for DMs. Ingest validates the exact frozen audience, and report reads recheck live membership and source authority. Search and notifications must not expose private report bodies or metadata.

For execution, a run freezes its definition, source set, audience and time boundary. Reads produce server-observed coverage receipts. Report storage, recipient indexes, progress advancement and publication receipt commit atomically; a repeated publication is idempotent. Missing or partial source reads cannot be described as complete. The first-run lookback is 24 hours; subsequent runs include unread delayed arrivals without repeating consumed messages.

Schedules are relay-managed derived jobs, atomically updated with the signed definition. Manual and scheduled triggers share one execution slot. Delivery reconciliation uses a durable request bound to the run, rather than assuming a generic relay-signed mention wakes an owner-only agent. #3858 and #7235 are relevant adjacent work; #6387 owns a related workflow-management boundary.

## Proposed contribution sequence

1. Agreed kinds, strict protocol validation, storage and relay authorization tests.
2. Bounded execution/read/publication primitives, scheduling integration and CLI.
3. Thin Desktop reader/setup, using existing agent controls, with synthetic screenshots and browser tests.

Mobile behavior should be agreed before the first slice: the current implementation is Desktop-only. A mobile reader can follow, but silent partial support should not be implied.

## Evidence and remaining limits

The fork's latest hardening validation recorded 17 database acceptance tests, 13 relay acceptance tests, 66 Pulse tests and three retries-disabled browser scenarios, plus workflow/core/native-link, migration, formatting and affected-package Clippy checks. Coverage includes pagination boundaries, delayed arrivals, failed-publication rollback, audience tampering, revocation, stale schedules, uncertain delivery and a synthetic 1,000-report history.

The coordinated local deployment passed installed reader/setup/archive/search acceptance. These are fork results, not results for an upstream branch. The full repository gate is not claimed green; six baseline PostgreSQL discovery failures remain separately identified. Fresh execution and real multi-human installed acceptance are separate from those automated fixtures.

The implementation bounds individual source pages and run lifetime, but an explicit aggregate input/output budget and honest budget-exhaustion behavior still need to be settled for the upstream producer. We should not equate pagination or a time lease with a token budget. Retention likewise requires an operator policy: archiving/deletion does not physically purge payloads or backups.

## Feedback requested

Would you accept this product direction and the sequence above? In particular:

1. Where should the human reader/setup live, and what mobile scope is required initially?
2. Which event kinds and delegated-read authority contract should the protocol use?
3. Should the execution/scheduling primitives be shared with #7235 or #6387, or remain a dedicated workflow action?
4. What run-budget and retention defaults should the first producer enforce?

Related: #4766 (Inbox catch-up), #4642 (pinned briefing/canvas), #3858 (scheduled mention authority), #7235 (operations digest), #2704 (kind allocation), #6387 (agent-owned workflows).