fix(dashboard): show "Needs You" when an agent parks on a frontend tool#552
Closed
adrienlacombe wants to merge 2 commits into
Closed
fix(dashboard): show "Needs You" when an agent parks on a frontend tool#552adrienlacombe wants to merge 2 commits into
adrienlacombe wants to merge 2 commits into
Conversation
- AGP 8.9.1 → 9.2.1 (built-in Kotlin: drop the standalone org.jetbrains.kotlin.android plugin; migrate kotlinOptions → kotlin.compilerOptions), Gradle 8.11.1 → 9.5.1, compileSdk 36 → 37 (targetSdk stays 36 — no runtime behavior change) - Kotlin 2.0.21 → 2.4.0, which unpins kotlinx-coroutines 1.9.0 → 1.11.0 and multiplatform-markdown-renderer-m3 0.26.0 → 0.41.0 - Compose BOM 2024.12.01 → 2026.05.01, core-ktx 1.19.0, kotlinx-serialization 1.7.3 → 1.11.0, OkHttp 4.12.0 → 5.4.0 - markdown-renderer ≥0.27 moved code/inline-code/link text colors out of markdownColor into typography; restyle via markdownTypography in ControlScreen and AskSheet with identical palette values Verified: assembleRelease, lintDebug, and testDebugUnitTest all pass on JDK 17 (matches CI's temurin 17). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
When an agent calls a frontend tool (AskUserQuestion / question / ui_*), the runner pauses the turn and sets the control run state to `waiting_for_tool`, but the mission's stored status stays `active` and the backend still lists it among running missions. The board flattened the running list into a single id set and `categorizeMission` returns "Running" for any mission in that set — so a mission blocked on a user question was shown as Running instead of Needs You. Track `waiting_for_tool` missions separately on the board, keep them out of the genuinely-running set, and categorize them as Needs You (the backend already exposes the distinction via `RunningMissionInfo.state`). The shared `categorizeMission(s)` helpers gain an optional waiting-for-tool input that takes priority over Running. mission-switcher / control-client read the live run state directly and already distinguish `waiting_for_tool`, so only the board needed the fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@adrienlacombe is attempting to deploy a commit to the LFG Labs Team on Vercel. A member of the Team first needs to authorize it. |
Owner
|
bugbot run |
Owner
|
Superseded by #556, which keeps your dashboard commit (@adrienlacombe) and (1) drops the bundled Android toolchain/dependency upgrade so it can land on its own, and (2) fixes a Cancel→Delete regression — excluding waiting_for_tool from the running set also flipped a parked (live) mission's card action to Delete, so it could be deleted instead of cancelled. #556 offers Cancel whenever the harness is alive. If you'd rather keep this PR and split the Android upgrade out, say so and I'll close #556 instead. |
Th0rgal
added a commit
that referenced
this pull request
Jun 17, 2026
…ol (supersedes #552) (#556) * fix(dashboard): show "Needs You" when an agent parks on a frontend tool When an agent calls a frontend tool (AskUserQuestion / question / ui_*), the runner pauses the turn and sets the control run state to `waiting_for_tool`, but the mission's stored status stays `active` and the backend still lists it among running missions. The board flattened the running list into a single id set and `categorizeMission` returns "Running" for any mission in that set — so a mission blocked on a user question was shown as Running instead of Needs You. Track `waiting_for_tool` missions separately on the board, keep them out of the genuinely-running set, and categorize them as Needs You (the backend already exposes the distinction via `RunningMissionInfo.state`). The shared `categorizeMission(s)` helpers gain an optional waiting-for-tool input that takes priority over Running. mission-switcher / control-client read the live run state directly and already distinguish `waiting_for_tool`, so only the board needed the fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(dashboard): keep Cancel (not Delete) for missions parked on a frontend tool Follow-up to the cherry-picked "Needs You" fix (superseding #552). Excluding waiting_for_tool missions from runningMissionIds correctly recategorizes them as "Needs You", but it also flipped their card action from Cancel to Delete — a live, mid-turn (parked) mission could be deleted outright instead of cancelled. Offer Cancel whenever the harness is alive (running OR waiting_for_tool). --------- Co-authored-by: adrienlacombe <6303520+adrienlacombe@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When an agent calls a frontend tool (
AskUserQuestion/question/ui_*), the runner pauses the turn and sets the control run state towaiting_for_tool, but the mission's stored status staysactiveand the backend still lists it among running missions. The board flattened the running list into a single id set, andcategorizeMissionreturns Running for any mission in that set (before the needs-you check) — so a mission blocked on a user question was shown as Running instead of Needs You.Fix
The backend already exposes the distinction via
RunningMissionInfo.state. The board now:waiting_for_toolmissions in a separate set,The shared
categorizeMission(s)helpers gain an optional waiting-for-tool input that takes priority over Running.mission-switcher/control-clientalready read the live run state and distinguishwaiting_for_tool, so only the board needed the change.Test plan
tsc --noEmitclean on touched files;eslintclean.categorizeMission(..., isWaitingForTool=true)→needs-you, andcategorizeMissionsplacing a waiting-for-tool mission in needs-you while a genuinely-running one stays in running.AskUserQuestionin a real mission;/api/control/runningreported the mission withstate: "waiting_for_tool"while its stored status stayedactive. Applying the categorization to that live data: before the fix →running, after →needs-you.🤖 Generated with Claude Code