chore: archive project-management and scaffold user-profile change

.gitignore

@@ -3,3 +3,48 @@
 .dolt/
 *.db
 .beads-credential-key
+
+# Environment files
+.env
+.env.*
+!.env.example
+
+# Python
+__pycache__/
+*.py[cod]
+*.pyo
+*.pyd
+*.so
+.python-version
+.venv/
+venv/
+env/
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+.coverage
+.coverage.*
+htmlcov/
+
+# Python packaging
+*.egg-info/
+build/
+dist/
+
+# Node / frontend
+node_modules/
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+apps/web/dist/
+
+# IDE / editor
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# OS
+.DS_Store
+Thumbs.db

openspec/changes/archive/2026-05-17-project-management/specs/ssh-keys/spec.md

@@ -1,6 +1,6 @@
 ## MODIFIED Requirements
 
-### Requirement: SSH Key Project Association
+### Requirement: Key Association
 The system SHALL only allow project default-key assignment using keys valid for the authenticated owner's project scope.
 
 #### Scenario: Valid default key assignment

openspec/changes/user-profile/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-05-17

openspec/changes/user-profile/README.md

@@ -0,0 +1,3 @@
+# user-profile
+
+Implement authenticated user profile read/update flow across API and frontend

openspec/specs/git-repo/spec.md

@@ -3,9 +3,7 @@
 ## Purpose
 
 Manage git repositories as bare repos on disk with metadata in database.
-
 ## Requirements
-
 ### Requirement: Repository Creation
 
 The system SHALL allow creating new bare git repositories.
@@ -36,14 +34,13 @@ The system SHALL list all user repositories.
 - THEN all their repos are listed with name, path, and last push date
 
 ### Requirement: Repository Deletion
+The system SHALL remove repository records when their owning project is deleted through authorized project deletion flow.
 
-The system SHALL support repository deletion.
+#### Scenario: Cascade repository cleanup
-
+- GIVEN a project with associated repositories
-#### Scenario: Delete repository
+- WHEN the project owner deletes the project
-- GIVEN an authenticated user
+- THEN repository records for that project are removed
-- WHEN they delete a repository
+- AND repository listing no longer includes removed records
-- THEN it's removed from disk
-- AND the database record is deleted
 
 ### Requirement: Duplicate Prevention
 

openspec/specs/project-management/spec.md

@@ -3,12 +3,9 @@
 ## Purpose
 
 Organize repositories into projects for grouping related work.
-
 ## Requirements
-
 ### Requirement: Project Creation
-
+The system SHALL allow authenticated users to create new projects and SHALL assign the creator as project owner.
-The system SHALL allow creating new projects.
 
 #### Scenario: Create project
 - GIVEN an authenticated user
@@ -16,27 +13,39 @@ The system SHALL allow creating new projects.
 - THEN a project record is created
 - AND the user is set as owner
 
-### Requirement: Project Listing
+#### Scenario: Reject unauthenticated creation
+- GIVEN a request without a valid authenticated session
+- WHEN it attempts to create a project
+- THEN the system responds with unauthorized status
 
-The system SHALL list all user projects.
+### Requirement: Project Listing
+The system SHALL list projects owned by the authenticated user, including related repositories and default SSH key metadata.
 
 #### Scenario: List projects
 - GIVEN an authenticated user
 - WHEN they view the projects page
 - THEN all their projects are listed with associated repositories
 
-### Requirement: Project Updates
+#### Scenario: Ownership-scoped listing
+- GIVEN multiple users with separate projects
+- WHEN one user requests their project list
+- THEN only that user's projects are returned
 
-The system SHALL support updating project details.
+### Requirement: Project Updates
+The system SHALL support updating project details for project owners only.
 
 #### Scenario: Update project
 - GIVEN a project owner
 - WHEN they update the name or description
 - THEN the changes are persisted
 
-### Requirement: Project Deletion
+#### Scenario: Non-owner update denied
+- GIVEN a user who is not the project owner
+- WHEN they attempt to update project details
+- THEN the system responds with forbidden status
 
-The system SHALL support cascading project deletion.
+### Requirement: Project Deletion
+The system SHALL support cascading project deletion for project owners.
 
 #### Scenario: Delete project
 - GIVEN a project owner
@@ -45,15 +54,24 @@ The system SHALL support cascading project deletion.
 - AND all associated SSH keys are removed
 - AND the project record is deleted
 
-### Requirement: Default SSH Key
+#### Scenario: Non-owner deletion denied
+- GIVEN a user who is not the project owner
+- WHEN they attempt to delete the project
+- THEN the system responds with forbidden status
 
-The system SHALL allow setting a default SSH key per project.
+### Requirement: Default SSH Key
+The system SHALL allow project owners to set a default SSH key per project and SHALL validate ownership for selected keys.
 
 #### Scenario: Set default key
 - GIVEN a project with SSH keys
 - WHEN the owner selects a default key
 - THEN it's used for git operations in that project
 
+#### Scenario: Reject foreign key assignment
+- GIVEN a project owner
+- WHEN they try setting a default SSH key that does not belong to their allowed scope
+- THEN the system rejects the request with validation error
+
 ## Dependencies
 
 - Database models: Project, User, GitRepository, SSHKey

openspec/specs/ssh-keys/spec.md

@@ -3,9 +3,7 @@
 ## Purpose
 
 Generate and manage SSH keys for git operations with external providers.
-
 ## Requirements
-
 ### Requirement: Key Generation
 
 The system SHALL generate Ed25519 SSH key pairs.
@@ -18,18 +16,17 @@ The system SHALL generate Ed25519 SSH key pairs.
 - AND the public key is stored in OpenSSH format
 
 ### Requirement: Key Association
+The system SHALL only allow project default-key assignment using keys valid for the authenticated owner's project scope.
 
-The system SHALL support user-level and project-level keys.
+#### Scenario: Valid default key assignment
+- GIVEN a project owner and an eligible SSH key
+- WHEN the owner sets the key as default for the project
+- THEN the project stores that key reference
 
-#### Scenario: User-level key
+#### Scenario: Invalid default key assignment
-- GIVEN an authenticated user
+- GIVEN a project owner
-- WHEN they generate a key without specifying a project
+- WHEN the owner attempts to set an ineligible SSH key as project default
-- THEN it's associated with their user account
+- THEN the system responds with validation failure
-
-#### Scenario: Project-level key
-- GIVEN an authenticated user with a project
-- WHEN they generate a key for that project
-- THEN it's associated with the project
 
 ### Requirement: Key Display