Dev Fleet blames the repo when it cannot resolve a trusted git

[chenmingwei23]

What

When Dev Fleet cannot resolve a trusted git, the failure is reported as a git
or repository problem, with no mention of the one setting that fixes it:

git worktree discovery failed in /path/to/checkout: no trusted executable for 'git'
in /usr/local/bin:/usr/bin:/bin:/opt/homebrew/bin:/home/linuxbrew/.linuxbrew/bin

Three things are wrong with that:

1. It misattributes the cause. The headline says worktree discovery failed in
   the checkout, so the user goes looking at their repository. The checkout is
   fine; the resolver never found a git it was willing to run.
2. It names no remedy. KIROCREW_DEVFLEET_BIN_GIT — an absolute path set in
   the operator-owned service environment — already exists and is exactly the fix,
   and the message does not mention it. The sibling error branch for a missing
   checkout does get this right ("Set KIROCREW_DEVFLEET_REPO … or clone it to
   ~/kirocrew"), so the pattern to follow is already in the same function.
3. It leaks the trusted PATH into the UI, which is noise the user cannot act on.

Report the unresolved tool directly, name it, and give the override.

Why

This is the generic form of the Windows discovery bug that #1633 tried to solve by
growing registry hints. Fixing the message covers every install shape at once —
portable git, MSYS2, scoop, a D: drive install, a tool on a path nobody
anticipated — on every OS, and it has no security surface: no probing, no trust
inference, no filesystem work on the request path. #1633 was closed in its favour
after eight review rounds established that synchronous discovery inside a
loop-bound resolver cannot both stay off the event loop and avoid reporting
nothing.

Correction to the original report

This issue was first filed claiming Dev Fleet renders a silent empty fleet when
the toolchain is missing. That is not true on current main and the claim was
not verified before filing — apologies. Reproduced by forcing _trusted_bin("git")
to return None and calling _discover_worktrees() directly:

• _discover_worktrees raises RuntimeError (it does not return []),
• api_dev_fleet_fleet catches it and returns {"worktrees": [], "error": ...},
• the UI renders its Discovery Error banner.

So the user does get an error. It is simply the wrong error, pointed at the wrong
subsystem, with no fix attached. That makes this a message-attribution defect, not
a silent-failure one — a smaller change than originally described, and no
frontend work: the banner already exists and already renders whatever reason the
backend supplies.

Additional Context

• Resolver: _trusted_bin() in src/kiro_crew/apps/builtins/dev_fleet/server.py;
  it fails closed and returns None.
• The message text comes from _run_cmd, which returns
  no trusted executable for <name> in <PATH> for any unresolvable bare argv name
  — so improving it there benefits every caller, not just discovery.
• _discover_worktrees then wraps that in its generic git worktree discovery failed in {MAIN_REPO} branch, which is what produces the misattribution.
• Related but separate: _resolve_primary_checkout() silently returns its input
  unchanged when git is unavailable, so MAIN_REPO is left un-normalized rather
  than reported. Harmless today, worth a look while in here.

[chenmingwei23]

Correcting my own filing: the original body claimed a silent empty fleet, which is not what main does. Reproduced by forcing _trusted_bin("git") to None — _discover_worktrees raises, the handler returns {"worktrees": [], "error": ...}, and the Discovery Error banner renders. The user gets an error; it is just the wrong one, aimed at the repository, with no remedy attached.

Rewritten as a message-attribution defect. Net effect on scope: backend only, no frontend change, since the banner already renders whatever reason the backend supplies.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: Confirmed on main, and the corrected framing in the follow-up comment matches the code. _run_git returns (-1, "", "no trusted executable for 'git' in <_TRUSTED_PATH>") at dev_fleet/server.py:833 when _trusted_bin("git") resolves to None; the discovery caller then folds that string into f"git worktree discovery failed in {MAIN_REPO}: ..." at line 1538, so an unresolved interpreter is reported as a fault in the user's checkout and the trusted PATH is echoed into the UI. The sibling branch immediately above (line 1532) already does this correctly for a missing checkout — it names the remedy (KIROCREW_DEVFLEET_REPO) — while the resolver-failure path never mentions KIROCREW_DEVFLEET_BIN_GIT, which is the actual fix and is already read at line 742. The same omission exists at the /api/sync site (line 2974). Starting an automated fix: distinguish the unresolved-tool failure from a genuine git error, name the tool and the KIROCREW_DEVFLEET_BIN_<TOOL> override in the message, and stop leaking the trusted PATH. This issue is now claimed by bolichen97's instance.