"Afraid to Ask" designed without Analyze
This commit is contained in:
aodulov
175
specs/004-afraid-to-ask/tasks.md
Normal file
175
specs/004-afraid-to-ask/tasks.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user