feat: implement repository clone mode with SSH key support

- Add clone_mode and branch fields to tool_instances - Add ssh_key_id to git_repositories for per-repo SSH key assignment - Implement host-side git cloning with branch selection (default: main) - Mount SSH keys into containers for git operations in clone mode - Add dirty state check on clone-mode instance deletion with confirmation - Update SessionsPage with mount/clone selector, branch input, SSH key display - Add SSH key selector to repository creation form - Add dirty delete confirmation modal with changed files list - Update API schemas and endpoints for new fields - Sync delta specs to main specs (git-repo, tool-instances, repo-clone-mode) - Archive completed OpenSpec change: repo-clone-mode-with-ssh - Document git requirement for custom tool types Quality gates: Frontend typecheck and build passed OpenSpec: repo-clone-mode-with-ssh archived with all tasks complete
2026-05-22 22:56:35 +02:00
parent 952a9f3234
commit 063a839790
95 changed files with 2002 additions and 392 deletions
@@ -1,34 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Stopping a session requires confirmation
-The system SHALL display a confirmation dialog before stopping a running session.
-
-#### Scenario: User initiates stop
- **WHEN** user clicks the "Stop" button on a running session
- **THEN** a confirmation dialog appears asking "Are you sure you want to stop this session?"
- **AND** the dialog provides "Cancel" and "Stop" options
-
-#### Scenario: User confirms stop
- **WHEN** user clicks "Stop" in the confirmation dialog
- **THEN** the session stops
- **AND** the dialog closes
-
-#### Scenario: User cancels stop
- **WHEN** user clicks "Cancel" in the confirmation dialog
- **THEN** the dialog closes
- **AND** the session remains running
-
-### Requirement: Deleted sessions disappear from UI immediately
-The system SHALL update the frontend state immediately after a session is successfully deleted.
-
-#### Scenario: Delete session
- **WHEN** user deletes a session
- **AND** the delete API call returns success
- **THEN** the session is removed from the visible list
- **AND** no page reload is required
-
-#### Scenario: Delete session failure
- **WHEN** user deletes a session
- **AND** the delete API call fails
- **THEN** the session remains in the list
- **AND** an error message is displayed
@@ -1,46 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Tool Lifecycle
-
-The system SHALL manage tool lifecycle operations including tunnel recreation.
-
-#### Scenario: Stop tool
- GIVEN a running tool instance
- WHEN the user stops it
- THEN `docker compose stop` is executed
- AND the cloudflared tunnel process is terminated
- AND status is updated to "stopped"
-
-#### Scenario: Start tool
- GIVEN a stopped tool instance
- WHEN the user starts it
- THEN `docker compose start` is executed
- AND a new temporary Cloudflare tunnel is created
- AND status is updated to "running"
-
-#### Scenario: Recreate tunnel
- GIVEN a running tool instance with a broken tunnel
- WHEN the user requests tunnel recreation
- THEN the existing cloudflared process is terminated
- AND a new temporary Cloudflare tunnel is created
- AND the instance URL is updated
- AND the instance shows as healthy
-
-## ADDED Requirements
-
-### Requirement: Tunnel Health Check
-
-The system SHALL check tunnel health for running instances.
-
-#### Scenario: Healthy tunnel check
- GIVEN a running instance with an active tunnel
- WHEN the health check runs
- THEN the tunnel URL responds with HTTP 2xx
- AND the instance is marked as healthy
-
-#### Scenario: Broken tunnel check
- GIVEN a running instance with a broken tunnel
- WHEN the health check runs
- THEN the tunnel URL does not respond with HTTP 2xx
- AND the instance is marked with tunnel_error
- AND a "Recreate Tunnel" button is shown
@@ -1,35 +0,0 @@
-## ADDED Requirements
-
-### Requirement: System monitors tunnel health
-The system SHALL periodically check if active tunnel URLs are reachable and mark them as erroneous if not.
-
-#### Scenario: Healthy tunnel
- **WHEN** a tunnel health check is performed on a running instance
- **THEN** the system receives an HTTP 2xx response
- **AND** the instance status remains "running"
-
-#### Scenario: Broken tunnel
- **WHEN** a tunnel health check is performed on a running instance
- **AND** the response is not HTTP 2xx or the request fails
- **THEN** the instance is marked with tunnel_error status
- **AND** a visual error indicator is displayed in the UI
-
-### Requirement: Users can recreate broken tunnels
-The system SHALL allow users to regenerate a temporary tunnel for a running instance without restarting the instance.
-
-#### Scenario: Recreate tunnel
- **WHEN** user clicks "Recreate Tunnel" button on an instance with a broken tunnel
- **THEN** the system stops the existing cloudflared process
- **AND** starts a new cloudflared tunnel
- **AND** updates the instance URL
- **AND** the new URL is displayed in the UI
-
-#### Scenario: Recreate tunnel success
- **WHEN** tunnel recreation completes successfully
- **THEN** the error indicator is removed
- **AND** the instance shows as healthy
-
-#### Scenario: Recreate tunnel failure
- **WHEN** tunnel recreation fails
- **THEN** the error indicator remains
- **AND** an error message is displayed to the user