Skip to content

[P0.3] Worktree isolation must not silently discard external-engine work (merge_back is dead code) #714

Description

@frankbria

Severity: critical | Category: data-integrity | Phase: P0.3

Problem

Verified: grep merge_back shows only the definition + docstring — zero call sites. External engines write to cf/<task_id> in the worktree, then cleanup() runs git worktree remove --force + git branch -D in a finally, destroying all changes; the task is marked COMPLETED with no surviving code.

Evidence

codeframe/core/worktrees.py:80 (defined), codeframe/core/sandbox/context.py:81 + codeframe/core/runtime.py:931 (cleanup force-deletes)

Acceptance criteria

  • On successful worktree run, merge_back() (or a patch export) runs before cleanup; merge conflicts surface as blockers and the branch is preserved on failure.
  • Integration test: a file created by the adapter under --isolation worktree exists on the base branch after the run.
  • (Acceptable interim: hard-reject --isolation worktree with a clear error until merge-back ships, so no work is lost.)

Dependencies

None


Filed from the SaaS launch-readiness audit. Atomic: one developer, one session. Work order: strictly P0.1 → P3.12 (no forward dependencies).

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0-blocker-betaCritical blocker - must fix before beta testingpriority:hightype:bugSomething is broken and needs fixing

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions