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>
53 lines
2.5 KiB
Markdown
53 lines
2.5 KiB
Markdown
## MODIFIED Requirements
|
|
|
|
### Requirement: Conversations keyed by email address
|
|
The system SHALL store conversations using the sender's normalized email address as the unique key, replacing thread-ID-based storage.
|
|
|
|
#### Scenario: Conversation file naming
|
|
- **WHEN** storing a conversation for `parent@example.com`
|
|
- **THEN** the system SHALL use a filename derived from the email address (e.g., `parent_at_example.com.json`)
|
|
|
|
#### Scenario: Conversation lookup
|
|
- **WHEN** loading a conversation for an incoming email
|
|
- **THEN** the system SHALL lookup by normalized sender email address
|
|
|
|
### Requirement: Registration updates stored as versions
|
|
The system SHALL store registration updates as separate versions, preserving the original and all subsequent changes for audit purposes.
|
|
|
|
#### Scenario: Initial registration stored
|
|
- **WHEN** a registration is completed for the first time
|
|
- **THEN** the system SHALL store it as version 1 with timestamp
|
|
|
|
#### Scenario: Registration update creates new version
|
|
- **WHEN** a parent requests changes to a completed registration
|
|
- **THEN** the system SHALL store the updated data as a new version
|
|
- **AND** the system SHALL preserve all previous versions
|
|
|
|
#### Scenario: Version metadata
|
|
- **WHEN** storing a registration version
|
|
- **THEN** the version SHALL include: version number, timestamp, and change summary (which fields changed)
|
|
|
|
### Requirement: Current registration accessible
|
|
The system SHALL provide easy access to the current (latest) registration data while preserving version history.
|
|
|
|
#### Scenario: Retrieve current registration
|
|
- **WHEN** the admin or system requests the current registration for an email address
|
|
- **THEN** the system SHALL return the most recent version
|
|
|
|
#### Scenario: Retrieve version history
|
|
- **WHEN** the admin requests registration history for an email address
|
|
- **THEN** the system SHALL return all versions in chronological order
|
|
|
|
## ADDED Requirements
|
|
|
|
### Requirement: Post-completion conversation state
|
|
The system SHALL support a "completed" conversation state that allows continued interaction for questions and updates.
|
|
|
|
#### Scenario: Conversation continues after completion
|
|
- **WHEN** a parent sends an email after their registration is complete
|
|
- **THEN** the system SHALL load the existing conversation and process the message
|
|
|
|
#### Scenario: Intent detection for post-completion messages
|
|
- **WHEN** processing a message in a completed conversation
|
|
- **THEN** the system SHALL detect intent: question, update request, or new child registration
|