Implementation Plan: Afraid to Ask

Branch: 004-afraid-to-ask | Date: 2025-10-13 | Spec: ../spec.md Input: Feature specification from /specs/004-afraid-to-ask/spec.md

Note: This template is filled in by the /speckit.plan command. See .specify/templates/commands/plan.md for the execution workflow.

Summary

This feature introduces a new "Afraid to ask" field in the response form, allowing anonymous users within a common session to submit sensitive ideas with maximum privacy. These ideas are initially visible only to the submitting user. They become publicly visible as a "Want" idea if they semantically comply with another user's "Want" or "Accept" idea within the same session. The technical approach will involve implementing the new UI field, a mechanism for semantic comparison (Google Cloud Natural Language API), and ephemeral server-side storage for encrypted "Afraid to ask" ideas and their compliance metadata, which will be purged upon session termination. All communication will occur over WebSockets. This ensures raw sensitive content is never persistently stored on the server and is not accessible via client-side developer tools.

Technical Context

Language/Version: Node.js (LTS), TypeScript 5.x (Backend), React (Frontend) Primary Dependencies: WebSocket library (Backend & Frontend), Express.js (Backend for initial connection/session management), Material-UI / MUI (Frontend), Google Cloud Natural Language API for semantic comparison Storage: Ephemeral server-side storage (e.g., in-memory cache or session store) for encrypted "Afraid to ask" ideas and compliance metadata, tied to the common session and purged upon session termination. Testing: Jest (Backend), React Testing Library (Frontend) Target Platform: Web (Browser-based frontend, Node.js backend) Project Type: Web application (frontend + backend) with WebSocket-only communication for core functionality. Performance Goals: Semantic comparison should be near real-time (e.g., <500ms for comparison). UI responsiveness should be consistent with existing application performance. WebSocket communication should be efficient. Constraints: Maximum privacy for "Afraid to ask" ideas, meaning they are not available to other users, even via developer tools. All server-side data related to "Afraid to ask" ideas (encrypted content and metadata) MUST be purged upon session termination. All real-time communication is via WebSockets. Scale/Scope: Initial implementation for existing user base within a common session, with potential for future scaling of WebSocket connections and LLM usage.

Constitution Check

GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.

I. Defined Technology Stack

Backend: Node.js (Compliant)
Frontend: React (Compliant)
UI Framework: Material Design 3 (Material-UI / MUI) (Compliant)
Containerization: Docker (Compliant - will be used for deployment)

II. UI/UX Consistency

All user interfaces MUST adhere to Material Design 3 principles and components. (Compliant - new UI element will follow MUI guidelines)

III. Container-First Development

All application services and development environments MUST run within Docker containers. (Compliant - existing project structure supports this)

IV. Test-Driven Development (TDD)

New features and bug fixes MUST follow a Test-Driven Development approach. (Compliant - tests will be written for new functionality)

V. API-First Design

The backend and frontend are decoupled and communicate via a well-defined API contract. (Compliant - new WebSocket message types and handlers will be defined for handling "Afraid to ask" ideas)

Project Structure

Documentation (this feature)

specs/004-afraid-to-ask/
├── plan.md              # This file (/speckit.plan command output)
├── research.md          # Phase 0 output (/speckit.plan command)
├── data-model.md        # Phase 1 output (/speckit.plan command)
├── quickstart.md        # Phase 1 output (/speckit.plan command)
├── contracts/           # Phase 1 output (/speckit.plan command)
└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)

Source Code (repository root)

backend/
├── src/
│   ├── models/
│   ├── services/
│   └── ws/              # New directory for WebSocket handlers
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
│       └── websocket.ts # Existing WebSocket service, now extended
└── tests/

Structure Decision: The existing web application structure with separate backend and frontend directories will be used. New WebSocket handlers will be added to backend/src/ws/, and new UI components and services will be added to frontend/src/components/, frontend/src/pages/, and frontend/src/services/ respectively. The existing frontend/src/services/websocket.ts will be extended.

Complexity Tracking

Violation	Why Needed	Simpler Alternative Rejected Because
Local storage for sensitive data	User's new privacy requirement (not available via developer tools) contradicts local storage assumption.	Local storage cannot guarantee the level of privacy required, as data is accessible via browser developer tools. A server-side solution for processing and ephemeral storage is necessary.
Persistent server-side storage for raw sensitive data	User's requirement to purge data on session termination.	Persistent storage would violate the privacy requirement of purging data upon session termination. Ephemeral storage is required.

5.8 KiB Raw Blame History