worktree:add fails in a fresh worktree and swallows stderr

What is wrong

Two defects that compound. Measured with Task 3.52 against nolte/kamerplanter-goose, which consumes taskfile-include-worktree.yaml as a remote include.

1. stderr is swallowed. Every failure of worktree:add reports exactly one line:

task: Failed to run task "worktree:add": exit status 1

Not one of the script's own >&2 diagnostics reaches the terminal — not the branch-prefix message, not the destination-exists message, not the fetch-fallback warning. It survives redirection: running with stdout and stderr sent to separate files leaves the stdout file empty and the stderr file holding only that one line. The script is careful to explain each failure; none of it is reachable.

2. The trust database is keyed per checkout path, so worktree:add cannot bootstrap a worktree. The real cause, once the messages were recovered by other means:

task: Taskfile "https://raw.githubusercontent.com/nolte/taskfiles/develop/src/taskfile-include-worktree.yaml" not trusted by user

Task parses every include at startup, and its trust decision is bound to the checkout it was granted in. A freshly created worktree is a new path, so it inherits no trust — and TASK_X_REMOTE_TASKFILES=1 with TASK_TRUSTED_HOSTS=raw.githubusercontent.com set does not lift it. task --yes does.

The consequence is circular for the worktree module specifically: the target whose job is to create a new working copy fails in every new working copy, and the module that provides it is exactly the one that cannot be loaded there.

What it is not

The script's own comment names a stale SSH_AUTH_SOCK as the cause of an intermittent failure here, so that was the first hypothesis. It is not this one. Run in isolation with the script's exact flags, the fetch succeeds:

GIT_TERMINAL_PROMPT=0 GIT_SSH_COMMAND="ssh -o BatchMode=yes -o ConnectTimeout=10" \
  git fetch origin develop --quiet </dev/null
# exit 0, ssh-agent reachable, key loaded

Because of defect 1, the fetch-fallback warning would have been invisible even if it had fired — the two defects hide each other.

Impact

The documented flow task worktree:add -- <branch> does not work from a clean consumer checkout, and the single-line error points nowhere. Working around it means dropping to git worktree add -b <branch> <dest> origin/develop, which reaches the same destination and branch but skips the seeded .resume/<slug>/plan.md — the plan-before-work gate the module exists to enforce.

Suggested direction

• Surface the script's stderr. A silent diagnostic is worse than none, because it costs the reader the time to find out it exists.
• Decide what worktree:add should do about include trust in a path Task has not seen. Failing with the actual message would already be a large improvement over the current single line.

Side note

task setup run inside a worktree reports pre-commit installed at <primary-checkout>/.git/hooks/pre-commit. Worktrees share the hook directory, so this is expected git behaviour rather than a bug — noting it only because the path in the output looks wrong at a glance.

Start by reproducing task worktree:add -- <branch> from a clean consumer checkout using taskfile-include-worktree.yaml, then inspect the worktree:add implementation and how its stderr is captured. Confirm the behavior with separate stdout and stderr files and determine how include trust is handled for a new worktree. Done means diagnostics reach stderr and the trust behavior is explicit and verified for the documented flow.