Roadmap: Meeting prep

Meeting preparation should start with one small, dated card per person: when we last interacted, what needs attention, and what the archive cannot tell us. This is the Meeting prep lane of #534, built on the calendar and meeting records tracked in #1200. This issue tracks the full workflow so the focused PRs can stay reviewable.

The implementation is in two draft PRs, #1330 and #1331; it has not shipped. Both depend on the meeting-record work from #1280, which was closed without merging. Resolving that prerequisite and rebasing the stack remain part of delivery.

Outcomes

• One deterministic person-card read across HTTP, CLI, and MCP, reusable before a meeting or a reply.
• Last interaction with its date and channel, up to three ranked, dated and cited items by default, meeting history, and explicit gaps. Items can include open loops, pending meeting actions, a recent profile fact change, and agenda items when those readers are available.
• An installed msgvault-meeting-prep skill that opens a meeting record, excludes the owner, deduplicates people, and builds at most eight resolved cards. Unresolved attendees and people beyond the cap remain visible.
• Clear separation between invitations and evidence of participation, including previous-occurrence context and pending actions where available.
• A useful result even when sources are stale: show warnings, item freshness, and missing coverage instead of inventing context or silently dropping uncertainty.

Delivery sequence

1. Resolve the meeting-record prerequisite from #1280, including its relationship to the calendar occurrence and meeting-link work in #1251 and #1252. #1280 is closed and unmerged; a replacement path remains to be settled before this stack can land.
2. Land the owner-only person-card read in #1330: shared bounded projection, identity resolution, HTTP API, generated clients, citations, ranking, gaps, and freshness. Implemented in draft; rebase and review against the resolved prerequisite remain.
3. Land the CLI, MCP tool, and installed workflow in #1331, after #1330. Implemented in draft; the skill composes meeting records and attendee cards, with documented fallback reads for authorized owner sessions on older daemons.

Open Loops integration remains optional. Without its reader, the card reports open_loops_unavailable; it must not imply that nothing is owed. Wiring that reader is follow-up integration, not a prerequisite for the bounded card workflow.

Design constraints

• Read-only and deterministic: no new model calls, task creation, drafts, sync requests, or contact promotion in the card path.
• Owner-only access in v1. Delegated cards require a separate authorization design; fallback reads must not bypass permissions.
• Private notes and sensitive attributes stay out. Source-controlled text is untrusted data, and citations come from validated references.
• Ambiguous identity matches require clarification. An observed address is not automatically a saved person.
• Bound reads and output, defaulting to three items and 16,384 content bytes; report truncation and unavailable readers explicitly.
• as_of changes evaluation time over current data, not the historical state of the archive.
• Reuse existing projections without an archive schema migration and preserve SQLite/PostgreSQL behavior.
• No meeting-level aggregate endpoint, web/TUI card view, scheduling, free/busy, proactive push, or new open-loop detection in this delivery.

Adjacent

• #534: broader People roadmap and the underlying profile, fact, activity, and brief surfaces.
• #1200: calendar and meeting records used to choose attendees and distinguish invitation from participation.
• #1311: shared source-freshness work in the Open Loops stack.
• #1224: scoped person access; delegated cards remain future work.