Bug Report: Mission orchestrator tools broken in droid 0.150.1 (ProposeMission + AskUser)

[mlcarl]

Bug Report: Mission orchestrator tools broken in droid 0.150.1 (ProposeMission + AskUser)

Droid version: 0.150.1 (latest as of 2026-06-18; droid update confirms "Already up to date!")
Platform: darwin 24.5.0 (macOS)
Severity: Blocker — cannot start ANY new mission. A previous mission completed successfully on the same version (19-hour run), so this is a regression.

---

Summary

Two mission-orchestrator tools are broken in droid 0.150.1, making it impossible to transition from the planning phase to execution:

1. ProposeMission — crashes on every call with Error: undefined is not an object (evaluating 'H.length'). Fails in 0.001-0.005s (local runtime, no network call). Reproduces with ANY proposal text, including a 2-word test.

2. AskUser — crashes on every call with Invalid AskUser questionnaire format at line 1: No [question] entries found. Reproduces with well-formed input matching the documented schema.

This is NOT a session-state issue. The user has confirmed the same bugs reproduce in:

• A completely fresh CLI restart (no --resume, same repo)
• A completely different repository with a brand-new mission

The bugs are deterministic and affect all new mission sessions in 0.150.1.

Reproduction

Minimal repro (ProposeMission)

1. Install droid 0.150.1
2. Start a new mission orchestrator session in any repository
3. Call ProposeMission with any proposal text (even "Test proposal")
4. Observe: Error: undefined is not an object (evaluating 'H.length') in 0.001-0.005s

Minimal repro (AskUser)

1. In the same session, call AskUser with any well-formed questionnaire input
2. Observe: Invalid AskUser questionnaire format at line 1: No [question] entries found

What does NOT fix it

• CLI restart (new droid invocation without --resume): bugs persist.
• Completely different repository + fresh mission: bugs persist. This rules out session-state corruption, repo-specific issues, and stale mission directory bindings.
• Deleting and recreating mission directories: does not help.
• Shortening the proposal: fails on a 2-word proposal. Not a content/length issue.
• droid update: already on 0.150.1, the latest version.
• Not reinstalling droid (to preserve artifacts): the bugs appeared without any reinstall or version change.

What DID work previously

A prior mission on the SAME droid version (0.150.1) completed successfully after a 19-hour run. The bugs appeared when starting a NEW mission after that completed mission. This suggests the regression is triggered by something in the mission lifecycle (e.g., a completed mission leaves state that breaks the next mission's initialization), OR a server-side change that coincided with the new mission attempt.

Evidence

ProposeMission error (every call, identical)

Error: undefined is not an object (evaluating 'H.length')

This is a JavaScriptCore-style error message indicating minified code dereferences an undefined variable H and accesses .length on it.

AskUser error (every call, identical)

Invalid AskUser questionnaire format at line 1: No [question] entries found

This occurs even with input strictly matching the documented schema: a JSON array of objects with id, question, and answerOptions (array of {label, description}).

Log signature (ProposeMission)

From ~/.factory/logs/droid-log-single.log. Every ProposeMission call produces this sequence:

[ToolExecutor] Using updated tool input | toolName: ProposeMission
[Tools] filterDecompTools called
[Tools] Orchestrator session - filtered tools | filtered: 18, orchestratorTools: ["propose-mission","start-mission-run","dismiss-handoff-items"]
[Tools] Checking for exit code 3 | toolName: ProposeMission, found: false
[Tools] Checking for exit code 2 | toolName: ProposeMission, found: false
[metrics_log_droid_mode_tool_execution_latency] | toolId: ProposeMission, isError: true, value: 0.005
[JsonRpcAdapter] Tool call complete | isError: true
[ToolExecutor] tool execution | name: ProposeMission, succeeded: false

Notable: there is NO network request log line between Using updated tool input and the error metrics. The failure is entirely local — the tool crashes before making any API call to the Factory server.

Session tag observation

The session carries a missionId tag:

"sessionTags":"[{\"name\":\"mission-session\",\"metadata\":{\"role\":\"orchestrator\",\"missionId\":\"<uuid>\"}}]"

This tag appears on every tool call. The missionId matches a mission directory under ~/.factory/missions/<uuid>/. However, since the bug reproduces in a completely fresh session in a different repo, the session tag alone is NOT the root cause — it is present in working and broken sessions alike.

Impact

• Complete blocker for starting new missions. No new mission can transition from planning to execution.
• Both tools that the orchestrator needs to interact with the user are broken (ProposeMission to submit the plan, AskUser to ask clarifying questions).
• No workaround found. CLI restart, fresh repo, deleting mission state — none of these fix it.
• Prior missions are not affected (the completed mission's artifacts are intact and readable).

Suspected Root Cause

Since the bug reproduces in fresh sessions across different repos, the root cause is likely one of:

1. A bug in the 0.150.1 tool handler itself (not state-dependent). The minified code for ProposeMission dereferences an undefined variable (H) before any network call. This could be a regression introduced in 0.150.1 that affects all mission orchestrator sessions.

2. A server-side contract change that the 0.150.1 client does not handle. If the Factory server changed the expected response shape for mission creation or session initialization, the client tool may receive an unexpected format, leading to the undefined dereference.

3. A mission-lifecycle issue: the bugs appeared after a prior mission completed successfully on the same version. Something about having a completed mission in ~/.factory/missions/ may interfere with new mission initialization. However, this is less likely given that the bug also reproduces in a different repo (though the ~/.factory/missions/ directory is shared across repos).

Suggested Fixes (for the Factory team)

1. Guard the undefined dereference: in the ProposeMission handler, check that the variable (minified as H) is non-null before accessing .length. Fall back to a clear error message instead of a crash.

2. Fix the AskUser input parser: the Invalid AskUser questionnaire format error suggests the parser does not recognize the documented schema. Verify the parser against the schema documented in the orchestrator system prompt.

3. Add a regression test: start a new mission in a clean environment (no prior missions) and verify ProposeMission + AskUser work. The fact that a 19-hour mission completed successfully on the same version suggests the regression was introduced by a server-side change or a race condition in mission initialization.

4. Investigate the mission lifecycle: check whether having a completed mission in ~/.factory/missions/ affects new mission creation. The user observed the bugs appearing after a completed mission.

Environment

Droid: 0.150.1
OS: darwin 24.5.0 (macOS Sequoia 15.5)
Model: BYOK (custom model via API)

Files That May Help Investigate

• ~/.factory/logs/droid-log-single.log — full tool execution log with trace IDs, showing the sub-millisecond local failure with no network call
• ~/.factory/missions/ — contains both the completed mission (working) and the failed new mission attempts
• ~/.factory/sessions/ — session state directory