docs: update spec to use remote_url instead of repo_id for git mounts

- Change git mount schema from repo_id to remote_url
- Update validation rules to check URL format instead of repo existence
- Update cloning scenarios to clone directly from URL
- Update UI scenarios to show URL input instead of repo selector
- Remove references to internal/existing repositories

openspec/changes/config-profile-git-mounts/specs/config-profile-git-mounts/spec.md

@@ -6,36 +6,34 @@ The system SHALL allow config profiles to include git repository mounts that bin
 #### Scenario: Create profile with git mount
 - **WHEN** a user creates or updates a config profile with `git_mounts` entries
 - **THEN** the profile stores each git mount with:
-  - `repo_id`: UUID of the referenced git repository
+  - `remote_url`: Direct git URL (e.g., "https://github.com/user/repo.git", "git@github.com:user/repo.git")
   - `source_path`: Path within the repository to mount (e.g., ".", "configs/")
   - `target_path`: Absolute path inside the container (e.g., "/home/user")
-  - `branch`: Optional branch or tag name (defaults to repository default branch)
+  - `branch`: Optional branch or tag name (defaults to "main")
 
 #### Scenario: Git mount validation
 - **WHEN** a profile with git mounts is saved
 - **THEN** the system validates that:
-  - The referenced repository exists and is owned by the user
-  - Repositories can be external (not tied to any project) or project-based
+  - `remote_url` is a valid git URL (starts with https://, git@, or ssh://)
   - `source_path` is a relative path (no leading `/`)
   - `target_path` is an absolute path (starts with `/`)
   - `target_path` does not contain path traversal sequences (`..`)
+  - No database lookup or repository existence check is performed (validation is deferred to clone time)
 
 #### Scenario: Profile with git mounts is resolved
-- **GIVEN** a config profile with git mounts referencing repository "dotfiles"
+- **GIVEN** a config profile with git mounts
 - **WHEN** the profile is resolved for instance startup
-- **THEN** the resolved profile includes the git mounts with repository details:
-  - Repository filesystem path
-  - Resolved branch name
-  - Source and target paths
+- **THEN** the resolved profile includes the git mounts as configured
+- **AND** repository cloning happens at instance startup time, not at profile resolution
 
 #### Scenario: Git mount is applied at instance startup
 - **GIVEN** a resolved profile with git mounts
 - **WHEN** an instance is started with this profile
 - **THEN** for each git mount:
-  - The repository filesystem path exists
-  - The source path within the repository exists
-  - A bind mount is created from `repo_path/source_path` to `container:target_path`
-- **AND** if the repository or path is missing, a warning is logged and the mount is skipped
+  - The repository is cloned from `remote_url` to a temporary location
+  - The source path within the cloned repository exists
+  - A bind mount is created from `clone_path/source_path` to `container:target_path`
+- **AND** if the clone fails or path is missing, a warning is logged and the mount is skipped
 
 ### Requirement: Git mounts support glob patterns
 The system SHALL support glob patterns in `source_path` for matching multiple files.
@@ -63,16 +61,16 @@ The system SHALL support glob patterns in `source_path` for matching multiple fi
 The system SHALL automatically clone referenced repositories to a persistent storage location on every new container creation. Each instance gets its own fresh clone.
 
 #### Scenario: Repository cloned on container creation
-- **GIVEN** a git mount referencing a repository
+- **GIVEN** a git mount with a `remote_url`
 - **WHEN** a new container is created with this profile
-- **THEN** the system clones the repository to a persistent location: `/data/repos/<user_id>/<repo_name>.git`
-- **AND** the clone proceeds asynchronously
+- **THEN** the system clones the repository from the URL to an instance-specific directory
+- **AND** the clone proceeds as part of instance startup
 - **AND** instance startup continues once clone completes
 
 #### Scenario: Existing clone updated on new container creation
-- **GIVEN** a repository that was previously cloned to the persistent location
+- **GIVEN** a repository that was previously cloned for this instance
 - **WHEN** a new container is created with this profile
-- **THEN** the system pulls the latest updates from the remote
+- **THEN** the system pulls the latest updates from the remote_url
 - **AND** checks out the specified branch (or default branch if not specified)
 - **AND** uses the updated clone for the bind mount
 
@@ -113,7 +111,7 @@ The system SHALL display git mounts in the config profile editor.
 - **GIVEN** a config profile with git mounts
 - **WHEN** the user views the profile in the UI
 - **THEN** the git mounts section displays each mount with:
-  - Repository name
+  - Git URL
   - Source path within repository
   - Target path in container
   - Branch/tag (if specified)
@@ -121,10 +119,10 @@ The system SHALL display git mounts in the config profile editor.
 #### Scenario: Add git mount via UI
 - **WHEN** a user adds a git mount in the profile editor
 - **THEN** they can:
-  - Select from all user-owned repositories (external repos not tied to any project are shown)
+  - Enter a git URL directly (https://, git@, or ssh://)
   - Specify the source path (with autocomplete or validation)
   - Specify the target path in the container
-  - Optionally select a branch/tag
+  - Optionally enter a branch/tag name
 
 #### Scenario: Remove git mount via UI
 - **WHEN** a user removes a git mount from the profile editor