4.3 KiB
Tasks for: Result Preparation Refactoring
Feature: 002-result-preparation-refactoring
Spec: spec.md
Plan: plan.md
Implementation Strategy
The implementation will be done in phases, focusing on refactoring the backend logic first, followed by the frontend updates. The backend and frontend tasks can be worked on in parallel.
MVP Scope: The Minimum Viable Product will include the refactored LLMService that can categorize desires and the updated ResultsDisplay component to show the new categories.
Phase 1: Foundational Tasks (Backend Refactoring)
These tasks focus on updating the backend to handle the new desire categorization logic.
- T001: [Test] Create a new test file
backend/tests/LLMService.refactor.test.tsto test the new desire categorization functionality. - T002: [Backend] Refactor
backend/src/services/LLMService.tsto replace the existinganalyzeDesiresmethod with one that uses the new prompt fromresearch.mdto categorize desires intoGo-to,Also good,Considerable,No-goes, andNeeds discussion. - T003: [Backend] Update the WebSocket handler in
backend/src/ws/index.tsto call the refactoredLLMService.analyzeDesiresmethod and broadcast the newDecisionobject to clients.
Phase 2: User Story 1 & 2 - Desire Submission & Contradiction Check
Goal: A user can submit their desires, and the system checks for inner contradictions. Independent Test: Submit a desire set with an inner contradiction (e.g., "I want a dog" and "I don't want any pets" in the same category) and verify that the system returns an error.
- T004: [Test] Add a test case to
backend/tests/LLMService.refactor.test.tsfor the inner contradiction check. - T005: [Backend] Implement a new method
checkForInnerContradictionsinbackend/src/services/LLMService.tsthat uses an LLM to detect contradictions within a single desire set. - T006: [Backend] Update the
SUBMIT_RESPONSEmessage handler inbackend/src/ws/index.tsto callcheckForInnerContradictionsbefore accepting a user's submission. If contradictions are found, send an error message back to the user. - T006a: [Backend] In the
SUBMIT_RESPONSEmessage handler inbackend/src/ws/index.ts, add validation to ensure each desire field does not exceed 500 characters. - T006b: [Frontend] [P] Update the
frontend/src/components/DesireForm.tsxcomponent to display a character counter under each input field.
Phase 3: User Story 3 - Cooperative Decision (Frontend Refactoring)
Goal: The frontend can correctly display the categorized results from the refactored backend.
Independent Test: Given a set of desires from multiple users, the frontend correctly renders the Go-to, Also good, Considerable, No-goes, and Needs discussion categories.
- T007: [Frontend] [P] Update the
Decisionand related types infrontend/src/hooks/useSession.tsto match the new backend structure defined indata-model.md. - T008: [Test] [P] Create a test file
frontend/src/components/ResultsDisplay.refactor.test.tsxto test the updatedResultsDisplaycomponent. - T009: [Frontend] Refactor the
frontend/src/components/ResultsDisplay.tsxcomponent to display the new categories (goTos,alsoGoods,considerables,noGoes,needsDiscussion).
Phase 4: Polish & Integration
- T010: Perform end-to-end testing of the entire workflow.
- T011: Clean up any old code related to the previous desire grouping logic.
- T012: Remove the old test files
backend/tests/llmService.test.tsandfrontend/src/components/ResultsDisplay.test.tsxafter verifying the new tests provide adequate coverage. - T013: [Test] Conduct performance testing to ensure that the desire submission process completes in under 1 minute as per SC-004.
Dependencies
- US1 & US2 are prerequisites for US3. The backend logic for contradiction checking and desire submission must be in place before the final results can be generated and displayed.
Parallel Execution
- The backend tasks in Phase 1 & 2 can be worked on in parallel with the frontend tasks in Phase 3.
- Backend Team: Can work on T001-T006.
- Frontend Team: Can work on T007-T009 using mock data until the backend is ready.