ag/unisono
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
09269190c16ee410b71c39818cbef3122450b51e
unisono/specs/004-afraid-to-ask/tasks.md

9.7 KiB
Raw Blame History

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

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

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

  • T011 [US1] Update frontend/src/components/DesireForm.tsx to add "Afraid to Ask" input field under "What you want".
  • T012 [US1] Update frontend/src/components/DesireForm.test.tsx to include tests for the new input field.
  • T013 [US1] Modify backend/src/routes/sessions.ts to accept afraidToAsk field in the session response submission endpoint (/sessions/{sessionId}/responses).
  • T014 [US1] Update backend/src/services/LLMService.ts to handle and store "Afraid to Ask" ideas privately (ephemeral storage).
  • T015 [US1] Update backend/src/tests/sessions.test.ts to include tests for submitting "Afraid to Ask" ideas.
  • 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

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

  • T022 [US3] Implement session termination logic in backend/src/routes/sessions.ts to purge all "Afraid to Ask" data.
  • T023 [US3] Update backend/src/tests/sessions.test.ts to include tests for data purging upon session termination.
  • 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

  • T025 Implement UI error handling and display for semantic matching service unavailability (FR-010).
  • T026 Implement UI placeholder display for "Harmonizing desires" during semantic matching analysis (FR-011).
  • 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).
  • T028 Conduct a privacy impact assessment (PIA) for the "Afraid to Ask" feature.
  • 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

# 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
Reference in New Issue View Git Blame Copy Permalink