docs(openspec): add FN-007 Git Connection Model change
- Add proposal, design, specs, and tasks for git connection model - Include provider adapter, credential storage, SSH key lifecycle specs - Add repository connection API and git operations specifications
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Credentials are stored encrypted
|
||||
The system SHALL store access tokens and SSH keys encrypted at rest.
|
||||
|
||||
#### Scenario: Store access token
|
||||
- **WHEN** a user saves an access token
|
||||
- **THEN** the system encrypts it with Fernet
|
||||
- **AND** stores the encrypted value in the database
|
||||
|
||||
#### Scenario: Retrieve access token
|
||||
- **WHEN** the system retrieves a credential for API calls
|
||||
- **THEN** it decrypts the value
|
||||
- **AND** returns the plaintext token
|
||||
|
||||
#### Scenario: List credentials without exposing values
|
||||
- **WHEN** a user lists their credentials
|
||||
- **THEN** the system returns metadata (name, provider, created_at)
|
||||
- **AND** masks the token value (showing only last 4 characters)
|
||||
|
||||
### Requirement: Credential storage supports multiple providers
|
||||
The system SHALL support storing credentials for different Git providers.
|
||||
|
||||
#### Scenario: Store GitHub token
|
||||
- **WHEN** a user adds a GitHub personal access token
|
||||
- **THEN** the system stores it with provider_type="github"
|
||||
|
||||
#### Scenario: Store GitLab token
|
||||
- **WHEN** a user adds a GitLab personal access token
|
||||
- **THEN** the system stores it with provider_type="gitlab"
|
||||
@@ -0,0 +1,29 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Git clone uses SSH credentials
|
||||
The system SHALL clone repositories using SSH keys.
|
||||
|
||||
#### Scenario: Clone repository
|
||||
- **WHEN** the system clones a repository
|
||||
- **THEN** it writes the SSH private key to a temporary file
|
||||
- **AND** sets GIT_SSH_COMMAND to use the key
|
||||
- **AND** executes git clone
|
||||
- **AND** cleans up the temporary key file
|
||||
|
||||
#### Scenario: Clone fails with invalid key
|
||||
- **WHEN** a clone operation fails due to authentication
|
||||
- **THEN** the system returns a clear error message
|
||||
- **AND** suggests checking deploy key permissions
|
||||
|
||||
### Requirement: Git fetch and push use credentials
|
||||
The system SHALL support fetch and push operations with SSH credentials.
|
||||
|
||||
#### Scenario: Fetch updates
|
||||
- **WHEN** the system fetches from a remote
|
||||
- **THEN** it uses the stored SSH key for authentication
|
||||
- **AND** returns the fetch result
|
||||
|
||||
#### Scenario: Push changes
|
||||
- **WHEN** the system pushes to a remote
|
||||
- **THEN** it uses the stored SSH key for authentication
|
||||
- **AND** returns the push result
|
||||
@@ -0,0 +1,35 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: GitHub adapter implements provider interface
|
||||
The system SHALL provide a GitHub adapter that implements the GitProvider interface.
|
||||
|
||||
#### Scenario: List repositories
|
||||
- **WHEN** the adapter lists repositories for an authenticated user
|
||||
- **THEN** it returns a list of repository objects with name, url, and default_branch
|
||||
|
||||
#### Scenario: Create deploy key
|
||||
- **WHEN** the adapter creates a deploy key for a repository
|
||||
- **THEN** it registers the SSH public key with GitHub
|
||||
- **AND** returns the key ID
|
||||
|
||||
#### Scenario: Validate connection
|
||||
- **WHEN** the adapter validates a token
|
||||
- **THEN** it verifies the token with GitHub API
|
||||
- **AND** returns user information
|
||||
|
||||
### Requirement: GitLab adapter implements provider interface
|
||||
The system SHALL provide a GitLab adapter that implements the GitProvider interface.
|
||||
|
||||
#### Scenario: List repositories
|
||||
- **WHEN** the adapter lists repositories for an authenticated user
|
||||
- **THEN** it returns a list of repository objects with name, url, and default_branch
|
||||
|
||||
#### Scenario: Create deploy key
|
||||
- **WHEN** the adapter creates a deploy key for a repository
|
||||
- **THEN** it registers the SSH public key with GitLab
|
||||
- **AND** returns the key ID
|
||||
|
||||
#### Scenario: Validate connection
|
||||
- **WHEN** the adapter validates a token
|
||||
- **THEN** it verifies the token with GitLab API
|
||||
- **AND** returns user information
|
||||
@@ -0,0 +1,42 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Repository connections can be created
|
||||
The system SHALL allow users to create connections to Git repositories.
|
||||
|
||||
#### Scenario: Connect GitHub repository
|
||||
- **WHEN** a user provides a GitHub repository URL and access token
|
||||
- **THEN** the system validates the URL and token
|
||||
- **AND** creates a RepositoryConnection record
|
||||
- **AND** generates an SSH key pair
|
||||
- **AND** registers the deploy key with GitHub
|
||||
|
||||
#### Scenario: Connect GitLab repository
|
||||
- **WHEN** a user provides a GitLab repository URL and access token
|
||||
- **THEN** the system validates the URL and token
|
||||
- **AND** creates a RepositoryConnection record
|
||||
- **AND** generates an SSH key pair
|
||||
- **AND** registers the deploy key with GitLab
|
||||
|
||||
#### Scenario: Reject invalid URL
|
||||
- **WHEN** a user provides an invalid repository URL
|
||||
- **THEN** the system returns a 400 error with validation message
|
||||
|
||||
### Requirement: Repository connections can be listed and retrieved
|
||||
The system SHALL allow users to list and view their repository connections.
|
||||
|
||||
#### Scenario: List connections
|
||||
- **WHEN** a user requests their repository connections
|
||||
- **THEN** the system returns a list with status and metadata
|
||||
|
||||
#### Scenario: Get connection details
|
||||
- **WHEN** a user requests a specific connection
|
||||
- **THEN** the system returns full details including SSH public key
|
||||
|
||||
### Requirement: Repository connections can be deleted
|
||||
The system SHALL allow users to delete repository connections.
|
||||
|
||||
#### Scenario: Delete connection
|
||||
- **WHEN** a user deletes a connection
|
||||
- **THEN** the system removes the deploy key from the provider
|
||||
- **AND** deletes the SSH key pair
|
||||
- **AND** marks the connection as deleted
|
||||
@@ -0,0 +1,28 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: SSH keys are generated per repository
|
||||
The system SHALL generate Ed25519 SSH key pairs for each repository connection.
|
||||
|
||||
#### Scenario: Generate key pair
|
||||
- **WHEN** a repository connection is created
|
||||
- **THEN** the system generates an Ed25519 key pair
|
||||
- **AND** stores the private key encrypted
|
||||
- **AND** returns the public key for deploy key registration
|
||||
|
||||
#### Scenario: Retrieve public key
|
||||
- **WHEN** a user requests the public key for a connection
|
||||
- **THEN** the system returns the SSH public key string
|
||||
|
||||
### Requirement: SSH keys support lifecycle operations
|
||||
The system SHALL support rotating and revoking SSH keys.
|
||||
|
||||
#### Scenario: Rotate key
|
||||
- **WHEN** a user rotates an SSH key
|
||||
- **THEN** the system generates a new key pair
|
||||
- **AND** updates the deploy key on the provider
|
||||
- **AND** deletes the old key pair
|
||||
|
||||
#### Scenario: Revoke key
|
||||
- **WHEN** a connection is deleted
|
||||
- **THEN** the system deletes the deploy key from the provider
|
||||
- **AND** securely deletes the local key pair
|
||||
Reference in New Issue
Block a user