# Implementation Plan: Inactive Sessions Purging, Form Data Persistence, and Centralized Snackbars **Branch**: `009-inactive-sessions-purging` | **Date**: четверг, 16 октября 2025 г. | **Spec**: D:\\Coding\\unisono\\specs\\009-inactive-sessions-purging\\spec.md **Input**: Feature specification from `/specs/009-inactive-sessions-purging/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 implements automatic purging of inactive user sessions, real-time persistence of unsubmitted form input values using WebSockets, and consistent display of snackbar notifications in the top right corner of the UI. ## Technical Context **Language/Version**: TypeScript 5.x, Node.js (LTS) **Primary Dependencies**: React, Material-UI / MUI, WebSocket library **Storage**: Ephemeral server-side session storage (in-memory/session store) **Testing**: Jest, React Testing Library **Target Platform**: Web (browser for frontend, Node.js server for backend) **Project Type**: Web application (frontend + backend) **Performance Goals**: Maintain performance and stability for up to 100 concurrent active user sessions **Constraints**: Session inactivity timeout configurable via environment variable **Scale/Scope**: Up to 100 concurrent active user sessions ## Constitution Check *GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.* ### I. Defined Technology Stack: PASS - Backend: Node.js - PASS - Frontend: React - PASS - UI Framework: Material Design 3 (Material-UI / MUI) - PASS - Containerization: Docker - PASS ### II. UI/UX Consistency: PASS - All user interfaces MUST adhere to Material Design 3 principles and components. - PASS ### III. Container-First Development: PASS - All application services and development environments MUST run within Docker containers. - PASS ### IV. Test-Driven Development (TDD): PASS - New features and bug fixes MUST follow a Test-Driven Development approach. - PASS ### V. API-First Design: PASS - The backend and frontend are decoupled and communicate via a well-defined API contract. - PASS ## 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) ``` # [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] |