# Tasks: Afraid to Ask Feature

**Input**: Design documents from `/specs/004-afraid-to-ask/`
**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/

**Tests**: The feature specification implies a need for testing to ensure privacy, matching logic, and UI behavior. Therefore, test tasks are included.

**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.

## Format: `[ID] [P?] [Story] Description`
- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
- Include exact file paths in descriptions

## Path Conventions
- **Web app**: `backend/src/`, `frontend/src/`

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Project initialization and basic structure

- [x] T001 Verify Node.js/TypeScript project with React, Material-UI, WebSocket library, Google Cloud Natural Language API dependencies are correctly configured in `package.json` and `tsconfig.json`.
- [x] T002 [P] Verify linting and formatting tools are configured in `backend` and `frontend`.

---

## Phase 2: Foundational (Blocking Prerequisites)

**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented

**⚠️ CRITICAL**: No user story work can begin until this phase is complete

- [x] T003 Ensure ephemeral server-side storage (in-memory/session store) is configured for encrypted session data.
- [x] T004 Verify existing WebSocket communication setup can be extended for real-time updates.
- [x] T005 Configure Google Cloud Natural Language API integration in the backend.
- [x] T006 [P] Implement structured logging for "Afraid to Ask" data lifecycle events (submission, matching, purging).
- [x] T007 [P] Implement metrics for semantic matching service performance and availability.
- [x] T008 Implement access control mechanisms to ensure only the submitting user can view their "Afraid to Ask" ideas before matching.
- [x] T009 Implement encryption for "Afraid to Ask" data at rest in ephemeral storage.
- [x] T010 Implement secure transmission (e.g., HTTPS/WSS) for "Afraid to Ask" data.

**Checkpoint**: Foundation ready - user story implementation can now begin in parallel

---

## Phase 3: User Story 1 - Submitting an "Afraid to Ask" Idea (Priority: P1) 🎯 MVP

**Goal**: Allow users to privately submit "Afraid to Ask" ideas.

**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).

### Implementation for User Story 1

- [x] T011 [US1] Update `frontend/src/components/DesireForm.tsx` to add "Afraid to Ask" input field under "What you want".
- [x] T012 [US1] Update `frontend/src/components/DesireForm.test.tsx` to include tests for the new input field.
- [x] T013 [US1] Modify `backend/src/routes/sessions.ts` to accept `afraidToAsk` field in the session response submission endpoint (`/sessions/{sessionId}/responses`).
- [x] T014 [US1] Update `backend/src/services/LLMService.ts` to handle and store "Afraid to Ask" ideas privately (ephemeral storage).
- [x] T015 [US1] Update `backend/src/tests/sessions.test.ts` to include tests for submitting "Afraid to Ask" ideas.
- [x] T016 [US1] Update `frontend/src/pages/SessionPage.tsx` to display the user's own "Afraid to Ask" ideas.

**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently

---

## Phase 4: User Story 2 - "Afraid to Ask" Idea Matching (Priority: P1)

**Goal**: Semantically match "Afraid to Ask" ideas and treat them as "Want" if a match is found.

**Independent Test**: A user's "Afraid to Ask" idea that matches another user's "Want" or "Accept" is treated as "Want" for the submitting user in the results. Conversely, an "Afraid to Ask" idea with no match is not displayed in the results.

### Implementation for User Story 2

- [x] T017 [US2] Implement semantic comparison logic in `backend/src/services/LLMService.ts` to compare "Afraid to Ask" ideas with "Want" or "Accept" ideas.
- [x] T018 [US2] Update `backend/src/routes/sessions.ts` to integrate semantic matching into session results generation.
- [x] T019 [US2] Update `backend/src/tests/LLMService.refactor.test.ts` (or create new test file) to include tests for semantic matching logic.
- [x] T020 [US2] Update `frontend/src/components/ResultsDisplay.tsx` to correctly display harmonized results, including matched "Afraid to Ask" ideas.
- [x] T021 [US2] Update `frontend/src/components/ResultsDisplay.refactor.test.tsx` (or create new test file) to include tests for displaying matched "Afraid to Ask" ideas.

**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently

---

## Phase 5: User Story 3 - Data Privacy and Ephemerality (Priority: P1)

**Goal**: Ensure maximum privacy and complete purging of "Afraid to Ask" data upon session termination.

**Independent Test**: After a session terminates, no "Afraid to Ask" data is retrievable from the server.

### Implementation for User Story 3

- [x] T022 [US3] Implement session termination logic in `backend/src/routes/sessions.ts` to purge all "Afraid to Ask" data.
- [x] T023 [US3] Update `backend/src/tests/sessions.test.ts` to include tests for data purging upon session termination.
- [x] T024 [US3] Update `frontend/src/services/websocket.ts` to handle session termination events and update UI accordingly.

**Checkpoint**: All user stories should now be independently functional

---

## Final Phase: Polish & Cross-Cutting Concerns

**Purpose**: Improvements that affect multiple user stories

- [x] T025 Implement UI error handling and display for semantic matching service unavailability (`FR-010`).
- [x] T026 Implement UI placeholder display for "Harmonizing desires" during semantic matching analysis (`FR-011`).
- [x] T027 Review and ensure adherence to general data privacy best practices for handling "Afraid to Ask" data, including data minimization and purpose limitation (`FR-012`).
- [x] T028 Conduct a privacy impact assessment (PIA) for the "Afraid to Ask" feature.
- [x] T029 Run quickstart.md validation.

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies - can start immediately
- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
- **User Stories (Phase 3+)**: All depend on Foundational phase completion
  - User stories can then proceed in parallel (if staffed)
  - Or sequentially in priority order (P1 → P2 → P3)
- **Polish (Final Phase)**: Depends on all desired user stories being complete

### User Story Dependencies

- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No dependencies on other stories
- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable

### Within Each User Story

- Tests MUST be written and FAIL before implementation
- Models before services
- Services before endpoints
- Core implementation before integration
- Story complete before moving to next priority

### Parallel Opportunities

- All Setup tasks marked [P] can run in parallel
- All Foundational tasks marked [P] can run in parallel (within Phase 2)
- Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
- All tests for a user story marked [P] can run in parallel
- Models within a story marked [P] can run in parallel
- Different user stories can be worked on in parallel by different team members

---

## Parallel Example: User Story 1

```bash
# Launch all tests for User Story 1 together:
Task: "Update frontend/src/components/DesireForm.test.tsx to include tests for the new input field."
Task: "Update backend/src/tests/sessions.test.ts to include tests for submitting \"Afraid to Ask\" ideas."

# Launch all models for User Story 1 together:
Task: "Update frontend/src/components/DesireForm.tsx to add \"Afraid to Ask\" input field under \"What you want\"."
Task: "Modify backend/src/routes/sessions.ts to accept `afraidToAsk` field in the session response submission endpoint (`/sessions/{sessionId}/responses`)."
Task: "Update backend/src/services/LLMService.ts to handle and store \"Afraid to Ask\" ideas privately (ephemeral storage)."
Task: "Update frontend/src/pages/SessionPage.tsx to display the user's own \"Afraid to Ask\" ideas."
```

---

## Implementation Strategy

### MVP First (User Story 1 Only)

1. Complete Phase 1: Setup
2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
3. Complete Phase 3: User Story 1
4. **STOP and VALIDATE**: Test User Story 1 independently
5. Deploy/demo if ready

### Incremental Delivery

1. Complete Setup + Foundational → Foundation ready
2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
3. Add User Story 2 → Test independently → Deploy/Demo
4. Add User Story 3 → Test independently → Deploy/Demo
5. Each story adds value without breaking previous stories

### Parallel Team Strategy

With multiple developers:

1. Team completes Setup + Foundational together
2. Once Foundational is done:
   - Developer A: User Story 1
   - Developer B: User Story 2
   - Developer C: User Story 3
3. Stories complete and integrate independently

---

## Notes

- [P] tasks = different files, no dependencies
- [Story] label maps task to specific user story for traceability
- Each user story should be independently completable and testable
- Verify tests fail before implementing
- Commit after each task or logical group
- Stop at any checkpoint to validate story independently
- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence
