When `git stash apply` exits non-zero without producing conflict markers
(typical causes: untracked-overwrite, path missing at HEAD, index-conflict
that git refuses to mark), the previous code logged the bare exception
message and abandoned the stash. Operators couldn't distinguish failure
shapes without grepping runtime logs, and the dev's uncommitted work was
left to manual recovery even when an automated path would have worked.
Three additions on top of the conflict-marker path that already exists:
1. Capture stderr from the failing `git stash apply` (execAsync attaches
stderr/stdout to the rejection) and surface it in the task feed and
any subsequent failure messages, so the operator sees `error: untracked
working tree files would be overwritten by merge:` directly instead of
hunting it in mergerLog.
2. Layer 1 fallback: extract the patch via `git stash show -p --binary`
and try `git apply --3way`. This is more permissive than `stash apply`
for several common shapes (notably untracked overwrites — `--3way`
produces conflict markers we can route to the existing AI resolver
where stash apply just refuses).
3. Layer 2 fallback: if `--3way` also hard-fails and smartConflictResolution
is enabled, spawn `runAiAgentForAutostashHardFail` with the patch text +
git stderr. The agent reconstructs the developer's edits on top of HEAD
by editing files directly, then the orchestrator scans for residual
conflict markers before declaring success and dropping the stash.
The existing conflict-marker path remains unchanged — only the previously-
abandoned hard-fail branch gains recovery. Stash is dropped on success at
every layer; on every failure path the stash is preserved for manual
recovery and the failure cause is surfaced to the task feed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
c16b030cf3