99 lines
7.4 KiB
Markdown
99 lines
7.4 KiB
Markdown
# Feature Specification: Afraid to Ask Feature
|
|
|
|
**Feature Branch**: `004-afraid-to-ask`
|
|
**Created**: October 13, 2025
|
|
**Status**: Draft
|
|
**Input**: User description: "Afraid to Ask. Requirements are in the file .context/afraid-to-ask.md"
|
|
|
|
## User Scenarios & Testing *(mandatory)*
|
|
|
|
### User Story 1 - Submitting an "Afraid to Ask" Idea (Priority: P1)
|
|
|
|
A user wants to express a sensitive desire without immediately revealing it to others. They use the new "Afraid to Ask" field to submit their idea.
|
|
|
|
**Why this priority**: Core functionality, enables users to express sensitive desires while maintaining privacy.
|
|
|
|
**Independent Test**: A user can successfully submit an "Afraid to Ask" idea and see it reflected in their own session view (if applicable, without revealing it to others yet).
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** a user is on the response form, **When** they enter text into the "Afraid to Ask" field and submit, **Then** the idea is recorded privately for that user.
|
|
2. **Given** a user has submitted an "Afraid to Ask" idea, **When** they view their own session details, **Then** their "Afraid to Ask" idea is visible to them.
|
|
|
|
---
|
|
|
|
### User Story 2 - "Afraid to Ask" Idea Matching (Priority: P1)
|
|
|
|
A user's "Afraid to Ask" idea is compared against other participants' "Want" or "Accept" desires. If a match is found, it's treated as a "Want" for the submitting user in the results; otherwise, it remains private and is not shown.
|
|
|
|
**Why this priority**: Defines the core logic for how "Afraid to Ask" ideas interact with other users' desires and ensures conditional visibility.
|
|
|
|
**Independent Test**: A user's "Afraid to Ask" idea that matches another user's "Want" or "Accept" is treated as a "Want" for the submitting user in the results. Conversely, an "Afraid to Ask" idea with no match is not displayed in the results.
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** User A submits an "Afraid to Ask" idea, and User B has a "Want" or "Accept" idea that semantically matches User A's "Afraid to Ask" idea, **When** the session results are generated, **Then** User A's "Afraid to Ask" idea is treated as a "Want" for User A in the results.
|
|
2. **Given** User A submits an "Afraid to Ask" idea, and no other user has a "Want" or "Accept" idea that semantically matches User A's "Afraid to Ask" idea, **When** the session results are generated, **Then** User A's "Afraid to Ask" idea does not appear in the results.
|
|
|
|
---
|
|
|
|
### User Story 3 - Data Privacy and Ephemerality (Priority: P1)
|
|
|
|
Users expect their "Afraid to Ask" ideas to be handled with maximum privacy and to be completely removed from the server once the session concludes.
|
|
|
|
**Why this priority**: Addresses critical privacy and data retention requirements, building user trust.
|
|
|
|
**Independent Test**: After a session terminates, no "Afraid to Ask" data is retrievable from the server, confirming complete data purging.
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** a session has terminated, **When** an attempt is made to retrieve "Afraid to Ask" data from the server, **Then** no such data is found.
|
|
|
|
## Requirements *(mandatory)*
|
|
|
|
### Functional Requirements
|
|
|
|
- **FR-001**: The system MUST provide an "Afraid to Ask" input field on the response form, located directly under the "What you want" field.
|
|
- **FR-002**: The system MUST ensure that "Afraid to Ask" ideas are initially private to the submitting user and not visible to other participants.
|
|
- **FR-003**: The system MUST semantically compare "Afraid to Ask" ideas with other users' "Want" or "Accept" desires.
|
|
- **FR-004**: If an "Afraid to Ask" idea semantically matches another user's "Want" or "Accept" desire, the system MUST treat it as a "Want" for the submitting user in the session results.
|
|
- **FR-005**: If an "Afraid to Ask" idea does not semantically match any other user's "Want" or "Accept" desire, the system MUST exclude it from the session results.
|
|
- **FR-006**: The system MUST ensure maximum privacy for "Afraid to Ask" ideas, preventing their exposure to other users unless a semantic match occurs as per FR-004.
|
|
- **FR-007**: The system MUST purge all "Afraid to Ask" data from the server upon session termination, leaving no traces.
|
|
- **FR-008**: "Afraid to Ask" ideas will NOT influence session results beyond matching other users' "Want" or "Accept" desires.
|
|
- **FR-009**: The system will NOT perform long-term storage or analytics of "Afraid to Ask" ideas.
|
|
- **FR-010**: The UI MUST display a specific error message and prevent form submission if the semantic matching service is unavailable or returns an error.
|
|
- **FR-011**: The UI MUST display a "Harmonizing desires" placeholder during the semantic matching analysis of "Afraid to Ask" ideas.
|
|
- **FR-012**: The system MUST adhere to general data privacy best practices for handling "Afraid to Ask" data.
|
|
|
|
### Key Entities *(include if feature involves data)*
|
|
|
|
- **User Idea**: Represents a user's desire, including "Want", "Accept", and "Afraid to Ask" types. Attributes include content and type. A single "Afraid to Ask" input field may contain one or multiple distinct ideas.
|
|
- **Session**: A collection of user ideas and their matching results, along with associated metadata.
|
|
|
|
## Success Criteria *(mandatory)*
|
|
|
|
### Measurable Outcomes
|
|
|
|
- **SC-001**: Users can successfully submit "Afraid to Ask" ideas without them being immediately visible to other participants.
|
|
- **SC-002**: "Afraid to Ask" ideas that semantically match other users' "Want" or "Accept" desires are correctly reflected as "Want" in the results for the submitting user in 100% of test cases.
|
|
- **SC-003**: "Afraid to Ask" ideas that do not semantically match any other user's "Want" or "Accept" desires are completely absent from the session results in 100% of test cases.
|
|
- **SC-004**: No "Afraid to Ask" data is retained on the server after a session has concluded, ensuring complete privacy and data purging within 5 seconds of session termination.
|
|
|
|
## Clarifications
|
|
|
|
### Session October 13, 2025
|
|
|
|
- Q: What explicit items are out-of-scope for the "Afraid to Ask" feature? → A: Handling of offensive/illegal "Afraid to Ask" ideas; "Afraid to Ask" ideas influencing session results beyond matching "Want" or "Accept"; Long-term storage or analytics of "Afraid to Ask" ideas.
|
|
- Q: What is the expected maximum number of "Afraid to Ask" ideas per session or per user? → A: No particular number. The field contains some text that can contain one or multiple ideas.
|
|
- Q: How should the UI behave if the semantic matching service is unavailable or returns an error? → A: Show the error message and prevent form submission.
|
|
- Q: What is the target latency for semantic matching of an "Afraid to Ask" idea? → A: No target. Let the LLM work on it and display `Harmonizing desires` placeholder during analysis.
|
|
- Q: Are there any specific compliance or regulatory requirements for handling sensitive "Afraid to Ask" data (e.g., GDPR, HIPAA)? → A: No specific regulatory requirements beyond general data privacy best practices.
|
|
|
|
### Edge Cases
|
|
|
|
- What happens when the "Afraid to Ask" field is left empty? (It should be ignored)
|
|
- How does system handle partial matches between "Afraid to Ask" ideas and other desires? (Assume exact or semantic match based on existing LLM service)
|
|
- What if a user submits multiple "Afraid to Ask" ideas? (Each is processed independently)
|
|
- The system does NOT provide moderation or filtering for offensive or illegal content submitted via "Afraid to Ask" ideas.
|