ag/unisono
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
272c4f6148b5dc7b7c2d19fe529361a93c988033
unisono/specs/004-afraid-to-ask/tasks.md
aodulov 272c4f6148 "Afraid to Ask" designed without Analyze
2025-10-13 10:44:17 +03:00

8.4 KiB
Raw Blame History

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

# 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 View Git Blame Copy Permalink