Supported no-force worktree removal after verified local preservation (Orca 1.4.224)

[LimyTax]

Supported no-force removal after verified preservation

Orca 1.4.224. An archive hook can preserve local data successfully, but ordinary CLI removal with --run-hooks still rejects nonignored untracked content. The installed CLI offers --force and --allow-failed-archive-hook; neither is acceptable for this scenario.

Is there a supported preservation-aware admission or preflight that consumes a verified archive receipt and retains mandatory archive-success, exact ownership, quiescence and PTY-stop proof, without force, staging, precleaning, changing ignores, Sleep or an internal UI override?

If unavailable, please identify the required native capability/change. Also specify branch preservation and partial-failure readback behavior. A successful external archive should not silently waive dirty/unknown ownership checks.

Public source reference: https://github.com/stablyai/orca/blob/2bb20586ebc39d605e16d95f57420e20a16e7485/src/main/runtime/runtime-registered-local-worktree-removal.ts

No real target deletion or workaround has been performed. No private repository data, paths, session content, account IDs or credentials are included.

[AmethystLiang]

Thanks for sharing this! Could you tell us a bit more about what your archive hook preserves and the workflow you’re trying to support? A small example and the exact removal error would help us understand the gap.

One thing we’d need to clarify is what “verified” means here: a successful archive hook tells Orca the script completed successfully, but doesn’t by itself prove that every file was backed up or that nothing changed afterward. How would you expect Orca to verify that receipt?

It would also help to understand what guarantees you need beyond --force --run-hooks, with archive-hook success still required. That context would help us work out whether there’s a simpler way to support your use case or whether a new capability is needed.