chore: archive user-config-management change

2026-05-18 16:08:52 +02:00
parent 94254ee3fd
commit fb5725947d
6 changed files with 20 additions and 20 deletions
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-05-18
@@ -0,0 +1,32 @@
+## Context
+
+The platform needs a simple key-value configuration system for user preferences like theme, editor, and git identity.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Store user config as JSONB in PostgreSQL
+- Support partial updates (PATCH semantics)
+- Apply theme in frontend on load
+- Provide settings UI
+
+**Non-Goals:**
+- Complex nested config structures
+- Config validation beyond type checking
+- Per-project config (global only)
+
+## Decisions
+
+1. **JSONB column for flexibility**
+   - Rationale: Simple key-value, no schema migrations for new keys
+   
+2. **Merge semantics for updates**
+   - Rationale: Frontend can update single key without sending entire config
+   
+3. **Lazy creation**
+   - Rationale: Config row created on first write, not on user creation
+
+## Risks
+
+- **[JSONB query performance]** → Only querying by user_id, not by config keys
+- **[No schema validation]** → Frontend validates known keys, backend accepts any JSON
@@ -0,0 +1,25 @@
+## Why
+
+Users need to store preferences and settings (theme, editor, git identity) that persist across sessions.
+
+## What Changes
+
+- Add UserConfig model for JSONB key-value storage
+- Add API endpoints for get/update user config
+- Add frontend settings page
+- Apply theme preference in frontend
+
+## Capabilities
+
+### New Capabilities
+- `user-config-management`: Store and manage user preferences
+
+### Modified Capabilities
+- `user-profile`: Include config in profile responses
+
+## Impact
+
+- New database model and migration
+- New API endpoints under /users/me/config
+- New frontend settings page
+- Theme application in AppShell
@@ -0,0 +1,42 @@
+## ADDED Requirements
+
+### Requirement: User Config Storage
+
+The system SHALL store user configuration as JSONB key-value pairs linked to the user.
+
+#### Scenario: Create config on first write
+- GIVEN an authenticated user with no config
+- WHEN they update settings
+- THEN a UserConfig row is created with their user_id
+
+### Requirement: Config Keys
+
+The system SHALL support these configuration keys:
+- `default_editor`: string
+- `theme`: "light" | "dark" | "system"
+- `git_user_name`: string
+- `git_user_email`: string
+
+#### Scenario: Update theme
+- GIVEN an authenticated user
+- WHEN they PATCH /users/me/config with {"theme": "dark"}
+- THEN only the theme key is updated
+- AND other keys remain unchanged
+
+### Requirement: Config Retrieval
+
+The system SHALL return user configuration on request.
+
+#### Scenario: Get config
+- GIVEN an authenticated user with config
+- WHEN they GET /users/me/config
+- THEN their full configuration is returned
+
+### Requirement: Frontend Theme Application
+
+The system SHALL apply the user's theme preference on application load.
+
+#### Scenario: Load with dark theme
+- GIVEN a user with theme="dark"
+- WHEN the app loads
+- THEN the dark CSS class is applied to the document
@@ -0,0 +1,20 @@
+## 1. Backend User Config API
+
+- [x] 1.1 Create UserConfig SQLAlchemy model with JSONB config column
+- [x] 1.2 Create Alembic migration for UserConfig table
+- [x] 1.3 Add GET /users/me/config endpoint
+- [x] 1.4 Add PATCH /users/me/config endpoint with merge semantics
+- [x] 1.5 Add backend tests
+
+## 2. Frontend Settings
+
+- [x] 2.1 Create settings API client (apps/web/src/api/settings.ts)
+- [x] 2.2 Create settings page with theme selector and git identity fields
+- [x] 2.3 Apply theme preference on app load in AppShell
+- [x] 2.4 Add /settings route to router
+
+## 3. Verification
+
+- [x] 3.1 Run backend checks (ruff, mypy, pytest)
+- [x] 3.2 Run frontend checks (typecheck, lint, build)
+- [x] 3.3 Verify docker-compose config