Summary

After approving a paused interactive workflow, the in-process auto-resume fails with Workflow '<name>' not found. Subsequent archon workflow resume <run-id> also fails with the same error and lists all bundled/global workflows but excludes the project-scoped workflow that the original archon workflow run had no trouble locating.

The original run succeeded in dispatching the workflow and reaching the approval gate — so workflow discovery clearly works at that point. Only the resume code path can't find the same file.

Environment

• Archon: 0.3.11 (Homebrew install, macOS arm64)
• Run mode: --no-worktree (workflow has worktree.enabled: false)
• Working directory at time of run: a live checkout of a fork of this repo (~/Documents/BV/Archon, branch production)
• Workflow path: .archon/workflows/sync-upstream.yaml in that same checkout
• The CLI auto-registered the codebase, pointing the registered source path at ~/.archon/workspaces/<owner>/<repo>/source/ (the canonical workspace clone), which is a different directory than the cwd of the run.

Repro

1. In a project checkout at path A, create .archon/workflows/foo.yaml with interactive: true, worktree.enabled: false, and at least one approval: node.
2. Path A is NOT the auto-registered workspace path (~/.archon/workspaces/<owner>/<repo>/source/). The workflow file exists in A but not in the workspace clone.
3. cd A && archon workflow run foo --no-worktree \"test\" → runs fine, pauses at approval.
4. archon workflow approve <run-id> → records the approval, then immediately tries to resume. Resume fails: Workflow failed: Workflow did not complete successfully.
5. archon workflow resume <run-id> → fails with Workflow 'foo' not found. and a list of available workflows that does not include foo.

In step 4 the workflow had partially executed nodes after the approval gate (a bash node updated a git branch) before failing — so resume started but couldn't complete because of the missing workflow definition.

Expected

approve and resume should look up the workflow definition using the same discovery rules as run (cwd-first, then global, then bundled). Concretely: if the run was started from cwd=A and the workflow was discovered there, resume should also find it there — or the registered codebase's recorded source path should be used and that path should be the same the run used.

Actual

Resume looks only inside the auto-registered workspace clone path (~/.archon/workspaces/<owner>/<repo>/source/), which does not contain the workflow file that lives only in the user's live checkout.

Workaround

Place the workflow file in ~/.archon/workflows/ (home-scoped/global) — resume can find it there.

Notes

• The half-executed bash node before the failure means a partially mutated repo state is left behind. Not destructive in our case (it just advanced a git branch we wanted to advance anyway), but in general half-executed approval-gated workflows could leave the user's repo in an unexpected state without a clear way to finish.
• Possibly related: when worktree.enabled: false, the workflow operates on the cwd of run, but resume seems to resolve the run's working directory via the codebase registration, not via the original run record.