Files
cleveragents-core/features/consolidated_sandbox.feature
T
HAL9000 f808abff86 chore(ci): fix pre-commit hook failures
Fix JSON syntax errors in .devcontainer/devcontainer.json (removed
invalid JS-style // comments) and .devcontainer/opencode.json (removed
90+ trailing commas). Apply auto-fixes for end-of-file and trailing
whitespace issues across 100+ files. Fix SIM105 ruff violations in
benchmarks/core_circuit_breaker_bench.py (use contextlib.suppress).

Note: The security fix from issue #7478 (validate_path startswith bypass)
was already delivered to master in commit e18ac5f2. This PR as currently
structured is non-atomic (35 commits across 10+ issues) and needs
significant restructure before merge. This commit only addresses the
CI/pre-commit failures.

ISSUES CLOSED: #7478
2026-06-14 09:51:14 -04:00

862 lines
36 KiB
Gherkin

Feature: Consolidated Sandbox
Combined scenarios from: copy_on_write_sandbox, cow_sandbox_coverage_boost, no_sandbox_coverage, sandbox_checkpoints, sandbox_copy_on_write_coverage, sandbox_factory_coverage
# ============================================================
# Originally from: copy_on_write_sandbox.feature
# Feature: Copy-on-write sandbox lifecycle
# ============================================================
Scenario: Create a copy-on-write sandbox
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
Then the cow sandbox should be in the "created" state
And the cow sandbox context should reference plan "plan-001"
And the cow sandbox context should have strategy metadata "copy_on_write"
And the cow sandbox path should exist
Scenario: Creating a sandbox with empty plan_id raises ValueError
Given a cow test directory is initialised
When a cow sandbox is created with empty plan_id
Then a cow ValueError should be raised with message "plan_id cannot be empty"
Scenario: Creating a sandbox with empty resource_id raises ValueError
Given a cow test directory is initialised
When a cow sandbox is prepared with empty resource_id
Then a cow ValueError should be raised with message "resource_id cannot be empty"
Scenario: Creating a sandbox with empty original_path raises ValueError
Given a cow test directory is initialised
When a cow sandbox is prepared with empty original_path
Then a cow ValueError should be raised with message "original_path cannot be empty"
Scenario: Creating a sandbox on a non-existent directory raises SandboxCreationError
Given a cow test directory is initialised
Given a cow non-existent directory
When a cow sandbox is created on the non-existent directory for plan "plan-001"
Then a cow SandboxCreationError should be raised
# --- Path resolution ---
Scenario: Resolve a path in the sandbox copy
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow path "data/file.txt" is resolved
Then the cow resolved path should be inside the sandbox copy
And the cow sandbox should be in the "active" state
Scenario: Path traversal is rejected
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow path "../etc/passwd" is resolved
Then a cow ValueError should be raised with message "Path traversal not allowed"
Scenario: Resolving a path on a cleaned-up sandbox raises SandboxStateError
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox is cleaned up
And the cow path "file.txt" is resolved on a cleaned-up sandbox
Then a cow SandboxStateError should be raised
# --- Commit ---
Scenario: Commit with no changes produces empty result
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox is committed
Then the cow commit result should indicate success
And the cow commit result should have 0 changed files
And the cow commit result should have 0 added files
And the cow commit result should have 0 deleted files
Scenario: Commit with a new file syncs it to original
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And a cow file "new_file.txt" is created in the sandbox with content "hello world"
And the cow sandbox is committed
Then the cow commit result should indicate success
And the cow commit result should have 1 added files
And the cow file "new_file.txt" should exist in the original directory with content "hello world"
Scenario: Commit with a modified file syncs the change
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow existing file "existing.txt" is modified in the sandbox with content "updated"
And the cow sandbox is committed
Then the cow commit result should indicate success
And the cow commit result should have 1 changed files
And the cow file "existing.txt" in the original should have content "updated"
Scenario: Commit with a deleted file removes it from original
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow existing file "existing.txt" is deleted from the sandbox
And the cow sandbox is committed
Then the cow commit result should indicate success
And the cow commit result should have 1 deleted files
And the cow file "existing.txt" should not exist in the original directory
Scenario: Commit on a cleaned-up sandbox raises SandboxStateError
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox is cleaned up
And the cow sandbox commit is attempted on cleaned-up sandbox
Then a cow SandboxStateError should be raised
# --- Rollback ---
Scenario: Rollback restores the sandbox to original state
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And a cow file "temp.txt" is created in the sandbox with content "temporary"
And the cow path "temp.txt" is resolved
And the cow sandbox is rolled back
Then the cow sandbox should be in the "rolled_back" state
And the cow file "temp.txt" should not exist in the sandbox
Scenario: Rollback on a non-active sandbox raises SandboxStateError
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox rollback is attempted on created sandbox
Then a cow SandboxStateError should be raised
Scenario: Rollback from COMMITTED restores original via pre-commit backup
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-rb-committed"
And the cow existing file "existing.txt" is modified in the sandbox with content "modified-for-commit"
And the cow sandbox is committed
Then the cow sandbox should be in the "committed" state
And the cow file "existing.txt" in the original should have content "modified-for-commit"
When the cow sandbox is rolled back
Then the cow sandbox should be in the "rolled_back" state
And the cow file "existing.txt" in the original should have content "original content"
Scenario: Rollback from COMMITTED with no changes is a no-op
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-rb-noop"
And the cow sandbox is committed
Then the cow sandbox should be in the "committed" state
When the cow sandbox is rolled back
Then the cow sandbox should be in the "rolled_back" state
And the cow file "existing.txt" in the original should have content "original content"
# --- Cleanup ---
Scenario: Cleanup removes the sandbox directory
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox is cleaned up
Then the cow sandbox should be in the "cleaned_up" state
And the cow sandbox path should not exist
Scenario: Cleanup is idempotent
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And the cow sandbox is cleaned up
And the cow sandbox is cleaned up again
Then the cow sandbox should be in the "cleaned_up" state
# --- Protocol properties ---
Scenario: Sandbox has a unique ULID identifier
Given a cow test directory is initialised
When a cow sandbox is instantiated
Then the cow sandbox_id should be a valid ULID
And the cow sandbox status should be "pending"
And the cow sandbox context should be None
# --- Diff computation ---
Scenario: Diff detects added, modified, and deleted files
Given a cow test directory is initialised
When a cow sandbox is created for plan "plan-001"
And a cow file "added.txt" is created in the sandbox with content "new"
And the cow existing file "existing.txt" is modified in the sandbox with content "changed"
And the cow existing file "to_delete.txt" is deleted from the sandbox
And the cow sandbox is committed
Then the cow commit result should have 1 added files
And the cow commit result should have 1 changed files
And the cow commit result should have 1 deleted files
# ============================================================
# Originally from: cow_sandbox_coverage_boost.feature
# Feature: Copy-on-write sandbox coverage boost
# ============================================================
Scenario: Creating a sandbox on a file (not directory) raises SandboxCreationError
Given a cowcb temporary file instead of a directory
When a cowcb sandbox is created on that file for plan "plan-err"
Then a cowcb SandboxCreationError should be raised
And the cowcb sandbox status should be "errored"
# --- get_path with _sandbox_path manually set to None ---
Scenario: get_path raises SandboxStateError when sandbox_path is None
Given a cowcb sandbox with status CREATED and sandbox_path None
When cowcb get_path is called with "file.txt"
Then a cowcb SandboxStateError should be raised with message "Sandbox path not set"
# --- commit with _sandbox_path manually set to None ---
Scenario: commit raises SandboxStateError when sandbox_path is None
Given a cowcb sandbox with status ACTIVE and sandbox_path None
When cowcb commit is called
Then a cowcb SandboxStateError should be raised with message "Sandbox path not set"
# --- commit triggers OSError during sync ---
Scenario: commit wraps OSError into SandboxCommitError
Given a cowcb test directory is initialised
And a cowcb sandbox is created and activated for plan "plan-oserr"
When the cowcb original directory is removed before commit
And cowcb commit is called
Then a cowcb SandboxCommitError should be raised
And the cowcb sandbox status should be "errored"
# --- rollback with _sandbox_path manually set to None ---
Scenario: rollback raises SandboxStateError when sandbox_path is None
Given a cowcb sandbox with status ACTIVE and sandbox_path None
When cowcb rollback is called
Then a cowcb SandboxStateError should be raised with message "Sandbox path not set"
# --- rollback triggers OSError during re-copy ---
Scenario: rollback wraps OSError into SandboxRollbackError
Given a cowcb test directory is initialised
And a cowcb sandbox is created and activated for plan "plan-rbfail"
When the cowcb original directory is removed before rollback
And cowcb rollback is called
Then a cowcb SandboxRollbackError should be raised
And the cowcb sandbox status should be "errored"
# --- cleanup when _sandbox_path is None ---
Scenario: cleanup succeeds when sandbox_path is None
Given a cowcb sandbox with status PENDING and sandbox_path None
When cowcb cleanup is called
Then the cowcb sandbox status should be "cleaned_up"
# --- cleanup when sandbox parent directory does not exist ---
Scenario: cleanup succeeds when sandbox parent directory is already gone
Given a cowcb test directory is initialised
And a cowcb sandbox is created for plan "plan-cleanparent"
When the cowcb sandbox parent directory is removed
And cowcb cleanup is called
Then the cowcb sandbox status should be "cleaned_up"
# --- commit with dst_dir that needs creation (added file in subdirectory) ---
Scenario: commit creates missing destination subdirectories for added files
Given a cowcb test directory is initialised
And a cowcb sandbox is created and activated for plan "plan-subdir"
When a cowcb file "newdir/nested/added.txt" is created in the sandbox
And cowcb commit is called
Then the cowcb commit should succeed
And the cowcb file "newdir/nested/added.txt" should exist in the original directory
# --- commit with file deleted from sandbox that is already missing from original ---
Scenario: commit handles deleted file not present in original
Given a cowcb test directory is initialised
And a cowcb sandbox is created and activated for plan "plan-delmissing"
When the cowcb file "existing.txt" is deleted from both sandbox and original
And cowcb commit is called
Then the cowcb commit should succeed
# ============================================================
# Originally from: no_sandbox_coverage.feature
# Feature: Non-sandboxed resource behaviour
# ============================================================
Scenario: A non-sandboxed resource rejects an empty resource identifier during setup
When a non-sandboxed resource is prepared with an empty identifier
Then the non-sandboxed setup should fail with a resource identifier error
Scenario: A non-sandboxed resource rejects an empty path during setup
When a non-sandboxed resource is prepared with an empty path
Then the non-sandboxed setup should fail with a path error
# --- Context before creation ---
Scenario: A non-sandboxed resource has no context before it is created
Given a non-sandboxed resource for "my-api" at "/srv/api"
Then the non-sandboxed resource should have no context
# --- Creation validation ---
Scenario: Creating a non-sandboxed resource with an empty plan identifier is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
When the non-sandboxed resource is created with an empty plan identifier
Then the non-sandboxed setup should fail with a plan identifier error
Scenario: Creating a non-sandboxed resource records the correct context
Given a non-sandboxed resource for "my-api" at "/srv/api"
When the non-sandboxed resource is created for plan "01JKXYZ1234567890ABCDEFGH"
Then the non-sandboxed context should reference plan "01JKXYZ1234567890ABCDEFGH"
And the non-sandboxed context should reference resource "my-api"
And the non-sandboxed context should use the original path as the sandbox path
And the non-sandboxed context should have strategy metadata "none"
# --- Path resolution ---
Scenario: Resolving a path before the resource is created is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
When a file path is resolved against the non-sandboxed resource
Then the non-sandboxed path resolution should be rejected as premature
Scenario: Resolving a path after cleanup is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created and committed and cleaned up
When a file path is resolved against the non-sandboxed resource
Then the non-sandboxed path resolution should be rejected as premature
Scenario: Resolving a path with directory traversal is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
When a file path containing directory traversal is resolved
Then the non-sandboxed path resolution should be rejected as unsafe
Scenario: The first path resolution activates a non-sandboxed resource
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
When the file "src/main.py" is resolved against the non-sandboxed resource
Then the non-sandboxed resource should be in the "active" state
And the resolved non-sandboxed path should combine the original path and file
Scenario: Subsequent path resolutions keep the resource active
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
And the file "first.py" has been resolved against the non-sandboxed resource
When the file "second.py" is resolved against the non-sandboxed resource
Then the non-sandboxed resource should be in the "active" state
# --- Commit ---
Scenario: Committing from a pending state is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
When the non-sandboxed resource is committed
Then the non-sandboxed commit should be rejected as premature
Scenario: Committing after cleanup is rejected
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created and committed and cleaned up
When the non-sandboxed resource is committed
Then the non-sandboxed commit should be rejected as premature
Scenario: A successful commit returns a positive result
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
When the non-sandboxed resource is committed
Then the non-sandboxed commit result should indicate success
And the non-sandboxed resource should be in the "committed" state
Scenario: A commit from the active state also succeeds
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
And the file "src/main.py" has been resolved against the non-sandboxed resource
When the non-sandboxed resource is committed
Then the non-sandboxed commit result should indicate success
# --- Rollback ---
Scenario: Rollback is always rejected for non-sandboxed resources
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
When the non-sandboxed resource is rolled back
Then the non-sandboxed rollback should be rejected as impossible
Scenario: Rollback is rejected even from the active state
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
And the file "src/main.py" has been resolved against the non-sandboxed resource
When the non-sandboxed resource is rolled back
Then the non-sandboxed rollback should be rejected as impossible
# --- Cleanup ---
Scenario: Cleaning up an already cleaned resource is harmless
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created and committed and cleaned up
When the non-sandboxed resource is cleaned up again
Then the non-sandboxed resource should remain in the "cleaned_up" state
Scenario: Cleanup after commit transitions to cleaned up
Given a non-sandboxed resource for "my-api" at "/srv/api"
And the non-sandboxed resource has been created for plan "01JKXYZ1234567890ABCDEFGH"
And the non-sandboxed resource has been committed
When the non-sandboxed resource is cleaned up
Then the non-sandboxed resource should be in the "cleaned_up" state
# --- Identity ---
Scenario: Each non-sandboxed resource receives a unique identifier
Given a non-sandboxed resource for "api-1" at "/srv/api1"
And another non-sandboxed resource for "api-2" at "/srv/api2"
Then the two non-sandboxed resources should have different identifiers
# ============================================================
# Originally from: sandbox_checkpoints.feature
# Feature: Sandbox Checkpoint and Rollback Hooks
# ============================================================
Scenario: Checkpoint created before plan execution
Given a checkpoint manager
Given a sandbox with files in a temporary directory
When I create a checkpoint with phase "pre_execute" and plan "plan-001"
Then a checkpoint should be returned
And the checkpoint phase should be "pre_execute"
And the checkpoint plan_id should be "plan-001"
And the checkpoint sandbox_id should match the sandbox
Scenario: Checkpoint created after successful execution
Given a checkpoint manager
Given a sandbox with files in a temporary directory
When I create a checkpoint with phase "post_execute" and plan "plan-001"
And I attach metadata "status" as "success"
Then a checkpoint should be returned
And the checkpoint phase should be "post_execute"
And the checkpoint metadata should contain key "status" with value "success"
# Rollback
Scenario: Rollback restores sandbox state on failure
Given a checkpoint manager
Given a sandbox with files in a temporary directory
And a checkpoint exists for the sandbox with phase "pre_execute" and plan "plan-001"
When I modify the sandbox files
And I rollback to the checkpoint
Then the rollback should succeed
And the sandbox files should match the original state
Scenario: Rollback returns false when snapshot path is missing
Given a checkpoint manager
Given a sandbox with files in a temporary directory
And a checkpoint with an invalid snapshot path
When I attempt to rollback to the invalid checkpoint
Then the rollback should fail
# Listing
Scenario: Multiple checkpoints maintain order
Given a checkpoint manager
Given a sandbox with files in a temporary directory
When I create a checkpoint with phase "pre_execute" and plan "plan-001"
And I create a checkpoint with phase "post_execute" and plan "plan-001"
And I create a checkpoint with phase "pre_apply" and plan "plan-001"
Then listing checkpoints for the sandbox should return 3 checkpoints
And the checkpoints should be in creation order
# Metadata
Scenario: Checkpoint metadata captures phase and plan information
Given a checkpoint manager
Given a sandbox with files in a temporary directory
When I create a checkpoint with phase "pre_execute" and plan "plan-002"
Then the checkpoint should have a valid ULID checkpoint_id
And the checkpoint should have a created_at timestamp
And the checkpoint should have a non-empty snapshot_path
# Deletion
Scenario: Deleting a checkpoint removes it from the list
Given a checkpoint manager
Given a sandbox with files in a temporary directory
And a checkpoint exists for the sandbox with phase "pre_execute" and plan "plan-001"
When I delete the checkpoint
Then the deletion should succeed
And listing checkpoints for the sandbox should return 0 checkpoints
Scenario: Deleting a non-existent checkpoint returns false
Given a checkpoint manager
When I delete a checkpoint with id "nonexistent-id"
Then the deletion should fail
# Plan executor integration (optional checkpoint manager)
Scenario: PlanExecutor works without checkpoint manager
Given a checkpoint manager
Given a plan lifecycle service
And a plan executor without checkpoint manager
Then the plan executor checkpoint_manager should be None
Scenario: PlanExecutor accepts optional checkpoint manager
Given a checkpoint manager
Given a plan lifecycle service
And a plan executor with a checkpoint manager
Then the plan executor checkpoint_manager should not be None
# PlanApplyService integration
Scenario: PlanApplyService works without checkpoint manager
Given a checkpoint manager
Given a plan lifecycle service
And a plan apply service without checkpoint manager
Then the plan apply service checkpoint_manager should be None
Scenario: PlanApplyService accepts optional checkpoint manager
Given a checkpoint manager
Given a plan lifecycle service
And a plan apply service with a checkpoint manager
Then the plan apply service checkpoint_manager should not be None
# ============================================================
# Originally from: sandbox_copy_on_write_coverage.feature
# Feature: CopyOnWriteSandbox uncovered lines and branches
# ============================================================
Scenario: create wraps OSError from copytree into SandboxCreationError
Given a cowcov test directory is initialised
And shutil.copytree is patched to raise OSError in cowcov
When a cowcov sandbox create is attempted for plan "plan-oserr"
Then a cowcov SandboxCreationError should be raised
And the cowcov error message should contain "Failed to copy directory"
And the cowcov sandbox status should be "errored"
# ------------------------------------------------------------------
# get_path() — second call when already ACTIVE (line 196 False branch)
# Covers missing branch 196 → 199
# ------------------------------------------------------------------
Scenario: get_path called twice stays in ACTIVE status
Given a cowcov test directory is initialised
And a cowcov sandbox is created for plan "plan-active"
When cowcov get_path is called with "file1.txt"
And cowcov get_path is called with "file2.txt"
Then the cowcov sandbox status should be "active"
And both cowcov resolved paths should be valid
# ------------------------------------------------------------------
# get_path() — _sandbox_path is None with ACTIVE status
# Covers line 200 and branch 196 False + 199 True
# ------------------------------------------------------------------
Scenario: get_path raises SandboxStateError when ACTIVE but sandbox_path is None
Given a cowcov sandbox forced to ACTIVE with sandbox_path None
When cowcov get_path is attempted with "file.txt"
Then a cowcov SandboxStateError should be raised with message "Sandbox path not set"
# ------------------------------------------------------------------
# get_path() — _sandbox_path is None with CREATED status
# Covers line 200 and branch 199 True
# ------------------------------------------------------------------
Scenario: get_path raises SandboxStateError when CREATED but sandbox_path is None
Given a cowcov sandbox forced to CREATED with sandbox_path None
When cowcov get_path is attempted with "data.csv"
Then a cowcov SandboxStateError should be raised with message "Sandbox path not set"
# ------------------------------------------------------------------
# commit() — _sandbox_path is None
# Covers line 230
# ------------------------------------------------------------------
Scenario: commit raises SandboxStateError when sandbox_path is None
Given a cowcov sandbox forced to ACTIVE with sandbox_path None
When cowcov commit is attempted
Then a cowcov SandboxStateError should be raised with message "Sandbox path not set"
# ------------------------------------------------------------------
# commit() — dst_dir is empty (branch 242 False → 244)
# Covers missing branch at line 242
# ------------------------------------------------------------------
Scenario: commit skips makedirs when dst_dir is empty string
Given a cowcov test directory is initialised
And a cowcov sandbox is created for plan "plan-dstdir"
And cowcov _compute_diff is patched to return a changed root file
And cowcov os.path.dirname is patched to return empty string
And cowcov shutil.copy2 is patched to no-op
When cowcov commit is attempted
Then the cowcov commit should succeed
And cowcov os.makedirs should not have been called
# ------------------------------------------------------------------
# commit() — deleted file not present in original (branch 249 False)
# Covers missing branch at line 249 → back to 247
# ------------------------------------------------------------------
Scenario: commit handles deletion when file already missing from original
Given a cowcov test directory is initialised
And a cowcov sandbox is created and activated for plan "plan-delmiss"
When the cowcov file "existing.txt" is deleted from both sandbox and original
And cowcov commit is attempted
Then the cowcov commit should succeed
# ------------------------------------------------------------------
# commit() — OSError during sync wraps into SandboxCommitError
# Covers lines 252-254
# ------------------------------------------------------------------
Scenario: commit wraps OSError during file sync into SandboxCommitError
Given a cowcov test directory is initialised
And a cowcov sandbox is created and activated for plan "plan-syncerr"
And a cowcov file "existing.txt" is modified in the sandbox
And cowcov shutil.copy2 is patched to raise OSError
When cowcov commit is attempted
Then a cowcov SandboxCommitError should be raised
And the cowcov sandbox status should be "errored"
# ------------------------------------------------------------------
# rollback() — _sandbox_path is None
# Covers line 297
# ------------------------------------------------------------------
Scenario: rollback raises SandboxStateError when sandbox_path is None
Given a cowcov sandbox forced to ACTIVE with sandbox_path None
When cowcov rollback is attempted
Then a cowcov SandboxStateError should be raised with message "Sandbox path not set"
# ------------------------------------------------------------------
# rollback() — OSError during re-copy wraps into SandboxRollbackError
# Covers lines 311-313
# ------------------------------------------------------------------
Scenario: rollback wraps OSError from copytree into SandboxRollbackError
Given a cowcov test directory is initialised
And a cowcov sandbox is created and activated for plan "plan-rbfail"
And cowcov shutil.copytree is patched to raise OSError for rollback
When cowcov rollback is attempted
Then a cowcov SandboxRollbackError should be raised
And the cowcov sandbox status should be "errored"
# ------------------------------------------------------------------
# cleanup() — _sandbox_path is None (branch 341 False → 347)
# Covers missing branch at line 341
# ------------------------------------------------------------------
Scenario: cleanup succeeds when sandbox_path was never set
Given a cowcov sandbox in PENDING state with sandbox_path None
When cowcov cleanup is called
Then the cowcov sandbox status should be "cleaned_up"
# ------------------------------------------------------------------
# cleanup() — parent directory already gone (branch 344 False → 347)
# Covers missing branch at line 344
# ------------------------------------------------------------------
Scenario: cleanup succeeds when parent directory is already removed
Given a cowcov test directory is initialised
And a cowcov sandbox is created for plan "plan-cleanmissing"
And the cowcov sandbox parent directory is manually removed
When cowcov cleanup is called
Then the cowcov sandbox status should be "cleaned_up"
# ============================================================
# Originally from: sandbox_factory_coverage.feature
# Feature: Sandbox factory strategy routing
# ============================================================
Scenario: The factory rejects an empty resource identifier
Given the sandbox factory is available
When a sandbox is requested with an empty resource identifier
Then the factory should reject the request due to a missing resource identifier
Scenario: The factory rejects an empty resource path
Given the sandbox factory is available
When a sandbox is requested with an empty resource path
Then the factory should reject the request due to a missing resource path
# --- None strategy (passthrough) ---
Scenario: The none strategy produces a passthrough sandbox
Given the sandbox factory is available
When a sandbox is requested for resource "web-api" at "/srv/api" using the none strategy
Then the factory should produce a passthrough sandbox
And the produced sandbox should be in the pending state
# --- Implemented strategies ---
Scenario: The git worktree strategy produces a git worktree sandbox
Given the sandbox factory is available
When a sandbox is requested for resource "repo-1" at "/src/repo" using the git worktree strategy
Then the factory should produce a git worktree sandbox
And the produced git worktree sandbox should be in the pending state
Scenario: The copy-on-write strategy produces a copy-on-write sandbox
Given the sandbox factory is available
When a sandbox is requested for resource "docs" at "/srv/docs" using the copy-on-write strategy
Then the factory should produce a copy-on-write sandbox
And the produced copy-on-write sandbox should be in the pending state
# --- Unimplemented strategies ---
Scenario: The transaction rollback strategy creates a TransactionSandbox
Given the sandbox factory is available
When a sandbox is requested for resource "db-main" at "postgres://db/main" using the transaction rollback strategy
Then the factory should produce a transaction sandbox in the pending state
Scenario: The snapshot strategy is not yet available
Given the sandbox factory is available
When a sandbox is requested for resource "corpus" at "/srv/corpus" using the snapshot strategy
Then the factory should indicate the strategy is not yet implemented
# --- Unknown strategy ---
Scenario: An unrecognised strategy name is rejected
Given the sandbox factory is available
When a sandbox is requested for resource "misc" at "/tmp/misc" using an unrecognised strategy
Then the factory should reject the request due to an unknown strategy
Scenario: The overlay strategy is supported
Given the sandbox factory is available
When the factory is asked whether the overlay strategy is supported
Then the factory should confirm the strategy is supported
Scenario: The versioning strategy is now unknown and rejected
Given the sandbox factory is available
When a sandbox is requested for resource "corpus" at "/srv/corpus" using the versioning strategy
Then the factory should reject the request due to an unknown strategy
# --- Support checks ---
Scenario: The none strategy is reported as supported
Given the sandbox factory is available
When the factory is asked whether the none strategy is supported
Then the factory should confirm the strategy is supported
Scenario: The git worktree strategy is reported as supported
Given the sandbox factory is available
When the factory is asked whether the git worktree strategy is supported
Then the factory should confirm the strategy is supported
Scenario: The copy-on-write strategy is reported as supported
Given the sandbox factory is available
When the factory is asked whether the copy-on-write strategy is supported
Then the factory should confirm the strategy is supported
Scenario: An unrecognised strategy is reported as unsupported
Given the sandbox factory is available
When the factory is asked whether an unrecognised strategy is supported
Then the factory should indicate the strategy is not supported
# --- Resource type strategy lookup (spec-aligned types) ---
Scenario: A git-checkout resource supports worktree, copy-on-write, and none
Given the sandbox factory is available
When the compatible strategies for a "git-checkout" resource are queried
Then the factory should return git worktree, copy-on-write, and none as compatible
Scenario: A git resource supports only the none strategy
Given the sandbox factory is available
When the compatible strategies for a "git" resource are queried
Then the factory should return only the none strategy as compatible
Scenario: A fs-mount resource supports copy-on-write, overlay, and none
Given the sandbox factory is available
When the compatible strategies for a "fs-mount" resource are queried
Then the factory should return copy-on-write, overlay, and none as compatible
Scenario: A fs-directory resource supports copy-on-write, overlay, and none
Given the sandbox factory is available
When the compatible strategies for a "fs-directory" resource are queried
Then the factory should return copy-on-write, overlay, and none as compatible
Scenario: A fs-file resource supports copy-on-write, overlay, and none
Given the sandbox factory is available
When the compatible strategies for a "fs-file" resource are queried
Then the factory should return copy-on-write, overlay, and none as compatible
Scenario: An api_endpoint resource supports only the none strategy
Given the sandbox factory is available
When the compatible strategies for an "api_endpoint" resource are queried
Then the factory should return only the none strategy as compatible
Scenario: An unknown resource type falls back to the none strategy
Given the sandbox factory is available
When the compatible strategies for an unknown resource type are queried
Then the factory should return only the none strategy as compatible