gurixandClaude Opus 4.5
b10ff7a4fe
Replace thread-ID-based conversation matching with email-address-based matching for more reliable conversation continuity. Key changes: - One conversation per email address (simpler model) - No data expiration (conversations persist indefinitely) - Post-completion support (questions and registration updates) - Versioned storage for registration updates (audit trail) - Admin notifications for registration changes This addresses the gap where parents sending new emails (instead of replying) would lose their registration progress. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
## Why
|
|
|
|
The current email agent implementation uses email thread IDs (from `Message-ID`, `In-Reply-To`, `References` headers) to match conversations. This breaks when a parent sends a new email instead of replying to the existing thread—they start a fresh conversation and lose all previously collected registration data.
|
|
|
|
Parents don't always use "Reply"—they may compose a new email, use a different device, or their email client may not preserve threading headers. The system should recognize them by their email address, not by email client threading behavior.
|
|
|
|
## What Changes
|
|
|
|
- **Match conversations by sender email address** instead of thread ID
|
|
- **One conversation per email address** — simple, permanent association
|
|
- **Remove data expiration** — no 30-day retention limit; conversations persist indefinitely
|
|
- **Handle post-completion interactions** — if registration is complete, detect whether the parent is asking a question or requesting updates to their registration
|
|
- **Version registration updates** — store changes alongside original data for admin audit trail
|
|
- **Notify admin of updates** — when a completed registration is modified, notify admin with change details
|
|
|
|
### Removed Features
|
|
- ~~1-month data retention for email conversations~~
|
|
- ~~Day 30 data clearing~~
|
|
- ~~"Your registration will expire" warning~~
|
|
|
|
### Retained Features
|
|
- Email reminders for incomplete registrations (Day 3, 10, 25) — still useful to nudge parents
|
|
|
|
## Capabilities
|
|
|
|
### Modified Capabilities
|
|
|
|
- `email-channel`: Change conversation matching from thread ID to sender email address; remove data expiration
|
|
- `registration-data-store`: Add versioned storage for registration updates; key conversations by email address
|
|
- `registration-notifications`: Add notification type for registration updates (not just new registrations)
|
|
|
|
### New Capabilities
|
|
|
|
*None — this modifies existing capabilities*
|
|
|
|
## Impact
|
|
|
|
- **Email channel**: Simpler matching logic; more reliable conversation continuity
|
|
- **Storage**: Conversations keyed by email address instead of thread ID; registration updates stored as versions
|
|
- **Admin workflow**: Admin sees change history when registrations are updated
|
|
- **Data retention**: No automatic deletion; conversations persist until manually removed
|
|
- **Spec updates**: `conversation-flow.md` timeout/retention section needs updating
|