Shepherd stuck waiting for `Shepherd verify stage` and `Shepherd explore stage`

[Pijukatel]

Here is output from session where the /Shepherd missed that the Shepherd verify stage and Shepherd explore stage were already finished

Session with user inputs in bold

I'll start a shepherd run for this task.
Ran skill/shepherd

Starting the shepherd run. First, let me set up the run directory and check the state of the target repo.

Now the triage — a quick orchestrator-owned skim of the repo to size the task.

I have enough for triage. Writing 1-triage.md:

Both the verify and explorer stages are now running in parallel in the background. Verify is building the claim ledger (_request_fact_check.md) — fact-checking which actors already use SDKs, what storage access is hardcoded, and whether the runtime's API can support the SDK's storage client. The explorer is mapping the codebase (_codebase_map.md) for the architect. I'll report back and dispatch the design stage once they complete.

The untracked files are shepherd's run plumbing under .shepherd/ — per the repo rules and the shepherd skill, those must never be committed. Let me confirm nothing else is untracked and locally exclude the run directory so the tree reads clean without staging anything.

ok what is going on?

Here's the state of the shepherd run, step by step:

    Run setup done. I created the run directory at /home/user/actor-runtime/.shepherd/ with your task recorded verbatim, plus the default shepherd config (1 reviewer roster + 2 final reviewers, 3 inner iterations max, plan-mode design gate).
    Triage done (no gate for this stage): decision PROCEED, complexity medium. The core finding: 3 of the 4 sample actors (sample_actor, sample_actor_caller, sample_actor_standby) are deliberately stdlib-only and touch storage either by writing the crawlee file-system layout directly to disk or via hand-rolled HTTP calls; only sample_actor_isathome uses real SDK packages. The requirements/*.md docs explicitly pin that "stdlib-only" convention, so they need updating along with the actors.
    Two background agents are running right now (this is the phase we're in):
        verify — fact-checking every claim in the request against the code, including the critical feasibility question: does the runtime's /v2 API actually implement the endpoints the Apify SDK's storage client calls when running "at home" (KVS set-record, dataset push, request-queue add, whatever Actor.init() touches)? Result goes to _request_fact_check.md.
        explorer — mapping the relevant code (actors, driver env-var injection, post-run disk import, storage routers, e2e tests) into _codebase_map.md for the architect.

    Neither has reported back yet. When they finish, I dispatch the architect to draft the design, then present the full design + success criteria to you for iteration and the design gate. No source files get touched until you approve the design.
    The git noise you saw: a stop hook complained about untracked files. Those are just the .shepherd/ run files, which shepherd never commits by design (that's a hard rule of the pipeline). I tried to add .shepherd/ to .git/info/exclude — a local-only tweak to quiet git status — and you rejected that command, which is fine; I've left it alone. The directory simply stays untracked.

One unrelated note: the Notion connector needs authorization (via your claude.ai connector settings) before its tools work in this session — not needed for this task.

Nothing is blocked on you right now — next update comes when the verify and explorer agents complete.

But to me they seem finished

Let me check — the files are the real handoff, so if the agents finished, their outputs should be on disk.
Checked which shepherd stage files exist

You're right — both output files are on disk. Reading them now.

[jirispilka]

Happened to me as well

Claude says this was a root cause.
"""
Proximate — notifications dropped after an interruption. Control experiment inside this same session: all 8 later background stages delivered their notifications normally — one even arrived bundled with another stop-hook firing, so hook noise alone doesn't break delivery. The only variable unique to the two lost ones: a user interruption (tool rejection) occurred between dispatch and completion. Inference: an interrupted turn clears the session's pending background-resume trigger; completions after that point don't re-invoke the orchestrator, and the run sits until the next human message. (Harness-internal — inferred from behavior, not directly inspectable.)
"""
The issues is that I did not interrupt the session 🤷🏻

[Pijukatel]

The issues is that I did not interrupt the session

Same for me. I stepped in only after I saw the task was stale.

I actually tasked /sheperd to fix this, but it got stuck a few times as well.