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
|