feat(resource): implement ResourceHandler create_sandbox/create_checkpoint/rollback_to/project_access methods #836

Closed
opened 2026-03-13 20:16:33 +00:00 by freemo · 0 comments
Owner

Metadata

  • Commit Message: feat(resource): implement ResourceHandler sandbox and checkpoint methods
  • Branch: feature/resource-handler-sandbox
  • Type: Feature
  • Priority: Low
  • MoSCoW: Could have
  • Points: 8
  • Milestone: v3.6.0

Background and Context

The ResourceHandler protocol defines 4 sandbox/lifecycle methods beyond the core CRUD operations (covered by sibling issue). These methods integrate the resource system with the sandbox and checkpoint subsystems:

  • create_sandbox(resource) -> SandboxResult — Create an isolated sandbox for the resource (e.g., git worktree, container clone)
  • create_checkpoint(resource) -> CheckpointResult — Create a checkpoint of the current resource state (e.g., git tag, filesystem snapshot)
  • rollback_to(resource, checkpoint) -> RollbackResult — Rollback a resource to a prior checkpoint state
  • project_access(resource) -> AccessResult — Check access permissions for the resource within the project scope

These are essential for the plan execution pipeline's safety guarantees: actions execute in sandboxes, checkpoints enable rollback on failure, and access control prevents unauthorized resource modification.

Acceptance Criteria

  • create_sandbox() implemented for git-checkout (git worktree), fs-directory (tmpdir copy), devcontainer (container clone)
  • create_checkpoint() implemented for git-checkout (git tag), fs-directory (snapshot/copy), database (savepoint)
  • rollback_to() implemented for git-checkout (git checkout), fs-directory (restore from snapshot), database (rollback to savepoint)
  • project_access() implemented for all handler types (permission check against project scope)
  • Sandbox creation is idempotent (creating twice returns existing sandbox)
  • Checkpoint naming follows convention: checkpoint-{plan_id}-{timestamp}

Definition of Done

This issue is complete when:

  • All subtasks below are completed and checked off.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.

Subtasks

  • Implement create_sandbox() for git-checkout, fs-directory, devcontainer handlers
  • Implement create_checkpoint() for git-checkout, fs-directory, database handlers
  • Implement rollback_to() for git-checkout, fs-directory, database handlers
  • Implement project_access() for all handler types
  • Tests (Behave): Add scenarios for sandbox create/destroy lifecycle
  • Tests (Robot): Add integration test for checkpoint → modify → rollback cycle
  • Verify coverage >=97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors
## Metadata - **Commit Message**: `feat(resource): implement ResourceHandler sandbox and checkpoint methods` - **Branch**: `feature/resource-handler-sandbox` - **Type**: Feature - **Priority**: Low - **MoSCoW**: Could have - **Points**: 8 - **Milestone**: v3.6.0 ## Background and Context The ResourceHandler protocol defines 4 sandbox/lifecycle methods beyond the core CRUD operations (covered by sibling issue). These methods integrate the resource system with the sandbox and checkpoint subsystems: - `create_sandbox(resource) -> SandboxResult` — Create an isolated sandbox for the resource (e.g., git worktree, container clone) - `create_checkpoint(resource) -> CheckpointResult` — Create a checkpoint of the current resource state (e.g., git tag, filesystem snapshot) - `rollback_to(resource, checkpoint) -> RollbackResult` — Rollback a resource to a prior checkpoint state - `project_access(resource) -> AccessResult` — Check access permissions for the resource within the project scope These are essential for the plan execution pipeline's safety guarantees: actions execute in sandboxes, checkpoints enable rollback on failure, and access control prevents unauthorized resource modification. ## Acceptance Criteria - [ ] `create_sandbox()` implemented for git-checkout (git worktree), fs-directory (tmpdir copy), devcontainer (container clone) - [ ] `create_checkpoint()` implemented for git-checkout (git tag), fs-directory (snapshot/copy), database (savepoint) - [ ] `rollback_to()` implemented for git-checkout (git checkout), fs-directory (restore from snapshot), database (rollback to savepoint) - [ ] `project_access()` implemented for all handler types (permission check against project scope) - [ ] Sandbox creation is idempotent (creating twice returns existing sandbox) - [ ] Checkpoint naming follows convention: `checkpoint-{plan_id}-{timestamp}` ## Definition of Done This issue is complete when: - All subtasks below are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. ## Subtasks - [ ] Implement `create_sandbox()` for git-checkout, fs-directory, devcontainer handlers - [ ] Implement `create_checkpoint()` for git-checkout, fs-directory, database handlers - [ ] Implement `rollback_to()` for git-checkout, fs-directory, database handlers - [ ] Implement `project_access()` for all handler types - [ ] Tests (Behave): Add scenarios for sandbox create/destroy lifecycle - [ ] Tests (Robot): Add integration test for checkpoint → modify → rollback cycle - [ ] Verify coverage >=97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors
freemo added this to the v3.6.0 milestone 2026-03-13 20:20:05 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
Reference
cleveragents/cleveragents-core#836
No description provided.