fix(runtime): agent_swarm advertises worktree agents in non-Git projects, and reports an all-failed batch as succeeded

[UncertaintyDeterminesYou4ndMe]

What happened

Two related defects that both make agent_swarm report a healthier state than reality.

1. Worktree agents are advertised as available in projects where they can never run.

implementation declares workspace: worktree (packages/runtime/src/agent-catalog.ts:159), and worktree provisioning hard-requires a Git project (packages/storage/src/git-worktree-child-executor.ts:172):

if (source.kind !== 'git' || !source.git) {
  throw new Error('Worktree child execution requires a Git project');
}

That constraint is correct and not in question. The problem is that the catalog already models "this agent cannot run here" and gets the predicate wrong. evaluateAgentDefinitionAvailability (agent-catalog.ts:271) does exactly the right thing:

if (definition.contract.workspace === AGENT_WORKSPACE_WORKTREE && !input.worktreeChildExecutorAvailable) {
  return { status: 'unavailable', reason: 'workspace_isolation_unavailable', ... };

but the value it is fed answers a different question (session-manager.ts:1001):

private hasWorktreeChildExecutor(): boolean {
  return this.deps.worktreeChildExecutor !== undefined;
}

This asks "is a worktree executor wired into this runtime?", not "can the current project do worktrees?". On Desktop the executor is always wired, so in a non-Git project implementation is still reported available. The model selects it in good faith and every item fails at dispatch.

The machinery, the status value, and the reason string all already exist. Only the predicate is incomplete.

2. A batch where every item failed is reported as a success.

The same batch rendered as a green check with a 18 ms duration, while its own summary line read 3 items · partial · 0 completed · 3 failed. A run in which nothing succeeded should not present as success — the model reads the batch outcome and continues as if it had results.

How to reproduce

1. Open a project directory that is not a Git repository.
2. Ask for work that fans out over independent items, so the model reaches for agent_swarm.
3. Call agent_list — implementation is listed as available despite being unusable here.
4. Dispatch a batch with profile: "implementation".
5. Every item fails in milliseconds with Worktree child execution requires a Git project, and the batch still renders as succeeded.

Deterministic.

Environment

• Maka commit: 62024d140
• OS: macOS 15 (Darwin 25.6.0), Apple Silicon
• Surface: Desktop, built from source
• Node.js: v22.17.0
• Provider/model: DeepSeek V4 Pro

Logs, screenshots, or additional context

Observed batch summary:

Agent Swarm ✓ 18 ms
3 items · partial · 0 completed · 3 failed
  framework_a   failed · IMPLEMENTATION
                Worktree child execution requires a Git project

For context on how a research task ended up on implementation at all: its contract is workspace: worktree + defaultWriteBack: patch, which is unambiguously the code-editing agent. The two profiles suited to read-only and research work (local_read, web_research) are both same-workspace + summary and need no Git. A model choosing implementation for analysis work is a poor choice on its own merits — but with availability reported as it is, nothing tells it otherwise until the batch has already been accepted and dispatched.

Suggested direction. Resolve the project location when computing availability so worktreeChildExecutorAvailable reflects whether the active project is a Git work tree, not merely whether the executor exists. resolveProjectLocation is already the function the executor itself uses, so the two can agree on one answer. The existing unavailable / workspace_isolation_unavailable shape then carries it to the model unchanged.

Separately, a batch whose items all failed should not report success. Whatever the terminal batch state is called, 0 completed · N failed should not render with the same affordance as a batch that produced results.