104 lines
4.9 KiB
Markdown
104 lines
4.9 KiB
Markdown
# Implementation Plan: Afraid to Ask Feature
|
|
|
|
**Branch**: `004-afraid-to-ask` | **Date**: October 13, 2025 | **Spec**: ../../specs/004-afraid-to-ask/spec.md
|
|
**Input**: Feature specification from `/specs/004-afraid-to-ask/spec.md`
|
|
|
|
## Summary
|
|
|
|
This feature introduces an "Afraid to Ask" input field, allowing users to privately submit sensitive ideas. These ideas are semantically matched against other participants' "Want" or "Accept" desires. If a match occurs, the idea is treated as a "Want" for the submitting user in the session results; otherwise, it remains private and is not displayed. The feature prioritizes maximum privacy, ephemerality (no server-side traces after session termination), and adheres to general data privacy best practices. UI provides feedback for semantic matching analysis and service unavailability.
|
|
|
|
## Technical Context
|
|
|
|
**Language/Version**: Node.js (LTS), TypeScript 5.x
|
|
**Primary Dependencies**: React, Material-UI / MUI, WebSocket library, Google Cloud Natural Language API
|
|
**Storage**: Ephemeral server-side storage (in-memory/session store) for encrypted session data, purged on session termination.
|
|
**Testing**: `npm test`
|
|
**Target Platform**: Web (frontend), Server (backend)
|
|
**Project Type**: Full-stack (frontend/backend)
|
|
**Performance Goals**: No specific target latency for semantic matching; UI will display a "Harmonizing desires" placeholder during analysis.
|
|
**Constraints**: Maximum privacy, ephemerality (no long-term storage or analytics of "Afraid to Ask" ideas), adherence to general data privacy best practices.
|
|
**Scale/Scope**: Designed for individual sessions; a single "Afraid to Ask" input field may contain one or multiple distinct ideas.
|
|
|
|
## Constitution Check
|
|
|
|
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
|
|
|
**Note**: The `constitution.md` file is currently in a template state with placeholders. A full check against specific, defined principles is not possible at this time. However, based on general software engineering best practices and the implied principles from the template, the following gates are considered:
|
|
|
|
- **Test-First (Implied)**: The feature specification includes detailed user stories and acceptance criteria, which align with a test-first approach. This will be further enforced during task breakdown and implementation. (PASS)
|
|
- **Observability (Implied)**: The feature's focus on privacy and ephemerality implies a need for careful logging and monitoring to ensure data is purged correctly and not exposed. This will be a key consideration during implementation. (PASS)
|
|
- **Simplicity (Implied)**: The feature aims to solve a specific problem with a focused scope, avoiding unnecessary complexity. (PASS)
|
|
- **Security & Privacy**: The feature explicitly prioritizes maximum privacy and ephemerality, aligning with strong security and privacy principles. (PASS)
|
|
|
|
**Overall Status**: Passed (based on implied principles and feature design).
|
|
|
|
## Project Structure
|
|
|
|
### Documentation (this feature)
|
|
|
|
```
|
|
specs/[###-feature]/
|
|
├── 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)
|
|
<!--
|
|
ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
|
|
for this feature. Delete unused options and expand the chosen structure with
|
|
real paths (e.g., apps/admin, packages/something). The delivered plan must
|
|
not include Option labels.
|
|
-->
|
|
|
|
```
|
|
# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
|
|
src/
|
|
├── models/
|
|
├── services/
|
|
├── cli/
|
|
└── lib/
|
|
|
|
tests/
|
|
├── contract/
|
|
├── integration/
|
|
└── unit/
|
|
|
|
# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
|
|
backend/
|
|
├── src/
|
|
│ ├── models/
|
|
│ ├── services/
|
|
│ └── api/
|
|
└── tests/
|
|
|
|
frontend/
|
|
├── src/
|
|
│ ├── components/
|
|
│ ├── pages/
|
|
│ └── services/
|
|
└── tests/
|
|
|
|
# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
|
|
api/
|
|
└── [same as backend above]
|
|
|
|
ios/ or android/
|
|
└── [platform-specific structure: feature modules, UI flows, platform tests]
|
|
```
|
|
|
|
**Structure Decision**: [Document the selected structure and reference the real
|
|
directories captured above]
|
|
|
|
## Complexity Tracking
|
|
|
|
*Fill ONLY if Constitution Check has violations that must be justified*
|
|
|
|
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
|
|-----------|------------|-------------------------------------|
|
|
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
|
|
| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
|