# Tasks: Afraid to Ask

**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 and correct display logic. 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 for the new feature.

- [ ] T001 Create `D:\Coding\unisono\specs\004-afraid-to-ask\contracts/` directory for API contracts (if any are defined later).
- [ ] T002 Configure Google Cloud Natural Language API client in `backend/src/services/LLMService.ts`.

---

## 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.

- [ ] T003 Implement client-side encryption/decryption utility for "Afraid to Ask" ideas in `frontend/src/services/encryption.ts`.
- [ ] T004 Implement server-side encryption/decryption utility for "Afraid to Ask" ideas in `backend/src/services/encryption.ts`.
- [ ] T005 Setup ephemeral server-side storage (in-memory cache or session store) for encrypted ideas and metadata in `backend/src/services/sessionStore.ts`.
- [ ] T006 Implement session management and purging logic for ephemeral storage on session termination in `backend/src/services/sessionManager.ts`.
- [ ] T007 Extend existing WebSocket service in `frontend/src/services/websocket.ts` to handle new message types for "Afraid to Ask" ideas.
- [ ] T008 Create base WebSocket handlers in `backend/src/ws/afraidToAskHandler.ts` for incoming "Afraid to Ask" messages.

**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**: A user can submit a sensitive idea, and it's stored privately, not publicly visible until compliance.

**Independent Test**: A user can submit an "Afraid to ask" idea, and verify it's recorded privately and not displayed publicly.

### Implementation for User Story 1

- [ ] T009 [US1] Add "Afraid to ask" field to `frontend/src/components/DesireForm.tsx`.
- [ ] T010 [US1] Update `frontend/src/components/DesireForm.test.tsx` to test the new field and its encryption/submission logic.
- [ ] T011 [US1] Modify `frontend/src/components/DesireForm.tsx` to encrypt and send "Afraid to Ask" ideas via WebSocket.
- [ ] T012 [US1] Implement WebSocket handler in `backend/src/ws/afraidToAskHandler.ts` to receive encrypted "Afraid to Ask" ideas, decrypt in memory, store encrypted version ephemerally, and set `privacyStatus` to `Private`.
- [ ] T013 [US1] Add unit tests for the new WebSocket handler in `backend/tests/ws/afraidToAskHandler.test.ts`.

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

---

## Phase 4: User Story 2 - Viewing Results with "Afraid to Ask" Ideas (Priority: P1)

**Goal**: "Afraid to Ask" ideas become publicly visible as "Want" ideas if they semantically comply with other users' "Want" or "Accept" ideas within the same session.

**Independent Test**: Submit various "Afraid to ask", "Want", and "Accept" ideas, then verify that compliant "Afraid to ask" ideas appear as "Want" ideas in the results, and non-compliant ones do not.

### Implementation for User Story 2

- [ ] T014 [US2] Implement semantic comparison logic using Google Cloud Natural Language API in `backend/src/services/LLMService.ts`.
- [ ] T015 [US2] Add unit tests for semantic comparison logic in `backend/tests/services/LLMService.test.ts`.
- [ ] T016 [US2] Modify `backend/src/ws/afraidToAskHandler.ts` to trigger semantic comparison when new "Want" or "Accept" ideas are submitted, or when a new "Afraid to Ask" idea is submitted.
- [ ] T017 [US2] Update `backend/src/ws/afraidToAskHandler.ts` to change `privacyStatus` of "Afraid to Ask" ideas to `Public` if they comply, and broadcast the update via WebSocket.
- [ ] T018 [US2] Update `frontend/src/components/ResultsDisplay.tsx` to correctly display compliant "Afraid to Ask" ideas as "Want" ideas.
- [ ] T019 [US2] Update `frontend/src/components/ResultsDisplay.test.tsx` to test the display logic for compliant "Afraid to Ask" ideas.

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

---

## Phase N: Polish & Cross-Cutting Concerns

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

- [ ] T020 Review and refine error handling for encryption/decryption and LLM calls.
- [ ] T021 Add comprehensive logging for "Afraid to Ask" idea lifecycle and privacy events.
- [ ] T022 Update `D:\Coding\unisono\specs\004-afraid-to-ask\quickstart.md` with instructions for setting up and testing the "Afraid to Ask" feature.
- [ ] T023 Perform end-to-end testing of the entire feature.

---

## 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).
- **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 (P1)**: Can start after Foundational (Phase 2) - Depends on US1 for ideas to compare against, but should be independently testable.

### Within Each User Story

- Tests (if included) 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 can run in parallel.
- All Foundational tasks can run in parallel (within Phase 2).
- Once Foundational phase completes, User Story 1 and User Story 2 can be worked on in parallel by different team members, though US2 will require US1's basic functionality to be in place for full testing.
- Within each user story, tasks that operate on different files and have no direct dependencies can be parallelized.

---

## Parallel Example: User Story 1

```bash
# Launch all tests for User Story 1 together:
Task: "Update frontend/src/components/DesireForm.test.tsx to test the new field and its encryption/submission logic."

# Launch implementation tasks for User Story 1 that can run in parallel:
Task: "Add \"Afraid to ask\" field to frontend/src/components/DesireForm.tsx"
Task: "Implement WebSocket handler in backend/src/ws/afraidToAskHandler.ts to receive encrypted \"Afraid to Ask\" ideas, decrypt in memory, store encrypted version ephemerally, and set privacyStatus to Private."
```

---

## 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. 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
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