bug(runtime-host): failed Windows Skill deletion blocks catalog and Host startup #5987

What happened

A workspace Skill deletion failed when Windows rejected the directory rename into the transaction's tombstone with EPERM. The durable deletion intent remained, and subsequent Skill catalog queries repeatedly attempted the same recovery and failed.

This affected more than the Skill being deleted: listing Skills, toggling another Skill, and opening another Skill's folder all failed with persistence_failed. Restarting Desktop then caused repeated Runtime Host startup failures with exit code 70; the connection remained connecting and readiness requests timed out.

The initial cause of Windows rejecting the rename has not been established. The persistent failure after the deletion error is confirmed by the startup diagnostic's error chain.

Expected behavior: A failed Skill deletion should provide an actionable recovery or cancellation path. A retained deletion intent should not leave the application in a persistent startup retry loop without a way to resolve it. Recovery must preserve path containment, content checks, and uncertain transaction outcomes.

How to reproduce

Observed sequence on Windows:

1. Run Desktop with a local Runtime Host and an installed workspace Skill at <DATA_ROOT>/skills/example-skill.
2. Delete that Skill from the UI. In the failing case, Windows rejects moving its directory into <DATA_ROOT>/.maka/skill-transactions/<TRANSACTION>/tombstone with EPERM.
3. The delete request returns commit_outcome_unknown and leaves the transaction on disk.
4. Refresh the Skill list, toggle another Skill, or open another Skill's folder: catalog queries return persistence_failed.
5. Fully quit and reopen Desktop: startup recovery retries the same directory move, Runtime Host candidates exit with code 70, and the Host never becomes ready.

The native Windows trigger is intermittent/unknown; this report does not claim a deterministic Windows lock reproduction.

Controlled verification: In a temporary data root on POSIX, denying write access to the source skills parent at the existing after_intent failpoint reproduced the delete error and subsequent catalog failures. Feeding that retained transaction through candidate startup recovery also reproduced exit code 70, with the filesystem error preserved in errorChain. This verifies the failure propagation, not the specific Windows cause.

Environment

• OS: Windows 11, build 10.0.26100, x64.
• Surface: Desktop / local Runtime Host.
• Bundled Node.js: 24.18.1.
• Electron: 43.4.1.
• Code reference: main@3597abe84356409ccc9fb649c761c1649abe941d.

Logs, screenshots, or additional context

Only the relevant error structure is reproduced below. All paths, Skill names, transaction identifiers, process identifiers, and timestamps have been removed or replaced with placeholders. No original diagnostic files or screenshots are attached.

skills:delete -> skill.catalog.mutate
commit_outcome_unknown:
  Skill transaction outcome is unknown; recover before retrying

Subsequent skill.catalog.query operations:
persistence_failed:
  Skill catalog persistence failed

Startup diagnostic:
reason: internal_startup_failure
errorChain:
  AggregateError:
    Runtime Host startup failed and shutdown did not complete cleanly
  SkillCatalogRepositoryError [persistence_failed]:
    Skill catalog persistence failed
  Error [EPERM]:
    operation not permitted, rename
    '<DATA_ROOT>/skills/example-skill'
    -> '<DATA_ROOT>/.maka/skill-transactions/<TRANSACTION>/tombstone'

Runtime Host candidate exit code: 70
Runtime Host connection state: connecting

Relevant implementation:

• replayDelete() moves the live directory to the tombstone.
• An exception after intent publication retains the transaction and returns commit_outcome_unknown.
• Skill recovery runs in the Host's startup state-recovery phase.

Related work:

• fix(storage): retry Windows session replacement under read locks #946 adds bounded retries for Windows session-file replacement under short-lived reader locks; it does not cover workspace Skill directory deletion.
• fix(storage): a non-convergent onboarding intent permanently bricks the runtime-policy store #3566 / fix(storage): clear obsolete onboarding intent #3571 address another retained-intent failure that prevented reopening a store, limited to a provably obsolete connection-onboarding intent.
• test(skills): cover Windows catalog #3964 adds Windows Skill Catalog coverage, without changing this deletion failure path.

Possible areas to investigate are bounded retries for transient Windows rename failures, safe resolution/cancellation of a deletion that has not moved the source, and an actionable startup recovery state. Persistent I/O errors and genuinely uncertain mutations still need to retain their safety guarantees.