[matchai]

codiff -w --walkthrough-file exits 0 even when the app can't apply the walkthrough, because the app opens detached. The app also silently drops any stop with an unresolved hunk id, so a single bad id loses that stop with no error. Agents then report the walkthrough as open when it isn't. A common cause is zsh, where an unbraced "$sha:h1" applies the :h modifier and produces .1.

The app now checks a CLI launch's walkthrough file against the diff before opening a window. A file that can't be applied opens nothing, and the CLI exits 1 with the reason:

$ codiff -w --walkthrough-file walkthrough.json HEAD
Walkthrough file could not be applied to this diff: Unresolved hunk ids: src/app.ts:.1. This diff's hunk ids: src/app.ts:f784…:h1, …
$ echo $?
1

 bin/codiff-app / bin/codiff.js
+  --walkthrough-result-file <tmp>
   open Codiff (detached)
+  wait for ready | unavailable (reason)            # exit 1 on unavailable
 app ready / second-instance
+  openLaunchWindow
+    read repository state
+    assertWalkthroughHunkIdsResolve()             # write ready | unavailable + reason
+    focusOrCreateWindow(…, state)                 # only when it can be applied

The window reuses the state the check read for its first diff view. --share runs the same id check before uploading. The skill no longer claims Codiff repairs drifted anchors, and the guide documents the exit code and the zsh trap.

Merge danger: two-way door, CLI launches with -w --walkthrough-file. A file that used to open with stops missing now opens nothing and fails the command.

This PR was written primarily with fx, a coding agent. I reviewed the change; the agent diagnosed the failure, wrote the fix and tests, and verified it against real walkthrough files.

banana banana banana

[cpojer]

Thank you! I'll take it from here.