feat: release 2.2.0 with PC-only tests and execution reliability fixes
Unify task scheduling and queue state, fix Android input and observation recovery, preserve screenshot paths, and match final review criteria accurately. Add collapsible copyable results and publish the complete 2.1.0 upgrade notes. Validation: 3189 backend tests, 326 frontend tests, 24 client tests, production build and quality gates.
This commit is contained in:
chenmingxuan committed
1 parent
fac4ccb760
commit
be6e8c2abd
79 files changed
+2263
-277
No files matched your search
@@ -178,7 +178,7 @@
|
||||
},
|
||||
{
|
||||
"name": "mobile_manage_task",
|
||||
"description": "Manages the lifecycle and retrieves the status of a background mobile automation task.\n\nThis is your primary diagnostic and control tool for tasks started by\n`mobile_run_task` or the web workspace. Poll with reasonable intervals while\nfollowing a running task; use request diagnostics for unexplained waits.\nYou can also steer a runner that is stuck or off-track, or stop a task.\n\n### Actions\n- lookup: Resolve a submission by request_id without starting or resubmitting it.\n- deletion_preview / delete: Show affected session IDs, then delete only when\n the user requested it (user_confirmed=true). Active tasks cannot be deleted.\n An exploration deletes its conversation runs, preserving independent reruns.\n- review: Record ONLY the user's explicitly stated passed/failed decision with\n review_reason and user_confirmed=true. Never label the agent's verdict as human.\n- **'status'**: Returns `trace_id`, `status` ('running'/'pausing'/'task_paused'/\n 'resuming'/'completed'/'failed'/'cancelled'/'interrupted'), `device_serial` (which phone owns this task in multi-device\n setups), `task_desc`, `model`, `elapsed_seconds`, a `test_summary` (when\n the run declared verification check items: machine-readable\n passed/failed/inconclusive/unchecked counts plus failed-item details —\n no need to parse report prose), `test_result` (Flash and Pro: status\n passed/failed/inconclusive/blocked, reason and evidence; completed only\n means execution ended), and `progress` (Flash:\n current turn, latest thought/action — intervene if turns climb without\n progress or the thought indicates it is stuck; Pro: the active task plan\n — check it still aligns with your goal).\n- **'pause'**: Requests a pause, returning `pausing` until the runner releases\n the device. Pro can interrupt a pending model response or read-only diagnostic;\n a device action already in progress must finish safely first. Check status\n for `task_paused` before assuming the device is free.\n- **'resume'**: Queues a paused task for its device again; optional `instruction`\n provides guidance before the next action.\n- **'inject_instruction'**: Injects real-time guidance mid-flight when the\n subagent errs, stalls, or loops. An in-flight model response or read-only\n helper is cancelled immediately, then the runner observes the device again\n and consumes the new guidance. An already-started device action finishes\n safely before the runner changes direction. Requires\n `instruction` (unless `release_loop=True`). To end a continuous\n monitoring task ([Loop:continuous] milestone) gracefully, you MUST pass\n `release_loop=True` — this is the only signal that unlocks the\n milestone's completion; natural-language \"please stop\" phrasing in\n `instruction` is NOT interpreted as a stop signal.\n- **'guidance_history'**: Lists submitted instructions with `pending` or\n `consumed` status; a submitted instruction is not proof it was applied.\n- **'stop'**: Forcefully terminates the subagent, immediately halting\n device interactions and releasing the device. Use when the task is done,\n irreparably broken, or running out of control. Prefer\n `inject_instruction` with `release_loop=True` when a monitoring task\n should wind down cleanly instead of being killed.\n\nArgs:\n action: `\"status\"`, `\"pause\"`, `\"resume\"`, `\"inject_instruction\"`,\n `\"guidance_history\"`, or `\"stop\"`.\n trace_id: The task's session identifier from `mobile_run_task` or the web UI.\n instruction: Guidance string; required for `inject_instruction`\n (optional when `release_loop=True`), omit otherwise.\n release_loop: With `inject_instruction`: explicit user stop signal\n that authorizes the subagent to complete continuous monitoring\n loops and finish the task gracefully.\n",
|
||||
"description": "Manages the lifecycle and retrieves the status of a background mobile automation task.\n\nThis is your primary diagnostic and control tool for tasks started by\n`mobile_run_task` or the web workspace. Poll with reasonable intervals while\nfollowing a running task; use request diagnostics for unexplained waits.\nYou can also steer a runner that is stuck or off-track, or stop a task.\n\n### Actions\n- lookup: Resolve a submission by request_id without starting or resubmitting it.\n- deletion_preview / delete: Show affected session IDs, then delete only when\n the user requested it (user_confirmed=true). Active tasks cannot be deleted.\n An exploration deletes its conversation runs, preserving independent reruns.\n- review: Record ONLY the user's explicitly stated passed/failed decision with\n review_reason and user_confirmed=true. Never label the agent's verdict as human.\n- **'status'**: Returns `trace_id`, `status` ('pending'/'running'/'pausing'/'task_paused'/\n 'resuming'/'completed'/'failed'/'cancelled'/'interrupted'), `device_serial` (which phone owns this task in multi-device\n setups), `task_desc`, `model`, `elapsed_seconds`, a `test_summary` (when\n the run declared verification check items: machine-readable\n passed/failed/inconclusive/unchecked counts plus failed-item details —\n no need to parse report prose), `test_result` (Flash and Pro: status\n passed/failed/inconclusive/blocked, reason and evidence; completed only\n means execution ended), and `progress` (Flash:\n current turn, latest thought/action — intervene if turns climb without\n progress or the thought indicates it is stuck; Pro: the active task plan\n — check it still aligns with your goal).\n- **'pause'**: Requests a pause, returning `pausing` until the runner releases\n the device. Pro can interrupt a pending model response or read-only diagnostic;\n a device action already in progress must finish safely first. Check status\n for `task_paused` before assuming the device is free.\n- **'resume'**: Queues a paused task for its device again; optional `instruction`\n provides guidance before the next action.\n- **'inject_instruction'**: Injects real-time guidance mid-flight when the\n subagent errs, stalls, or loops. An in-flight model response or read-only\n helper is cancelled immediately, then the runner observes the device again\n and consumes the new guidance. An already-started device action finishes\n safely before the runner changes direction. Requires\n `instruction` (unless `release_loop=True`). To end a continuous\n monitoring task ([Loop:continuous] milestone) gracefully, you MUST pass\n `release_loop=True` — this is the only signal that unlocks the\n milestone's completion; natural-language \"please stop\" phrasing in\n `instruction` is NOT interpreted as a stop signal.\n- **'guidance_history'**: Lists submitted instructions with `pending` or\n `consumed` status; a submitted instruction is not proof it was applied.\n- **'stop'**: Forcefully terminates the subagent, immediately halting\n device interactions and releasing the device. Use when the task is done,\n irreparably broken, or running out of control. Prefer\n `inject_instruction` with `release_loop=True` when a monitoring task\n should wind down cleanly instead of being killed.\n\nArgs:\n action: `\"status\"`, `\"pause\"`, `\"resume\"`, `\"inject_instruction\"`,\n `\"guidance_history\"`, or `\"stop\"`.\n trace_id: The task's session identifier from `mobile_run_task` or the web UI.\n instruction: Guidance string; required for `inject_instruction`\n (optional when `release_loop=True`), omit otherwise.\n release_loop: With `inject_instruction`: explicit user stop signal\n that authorizes the subagent to complete continuous monitoring\n loops and finish the task gracefully.\n",
|
||||
"inputSchema": {
|
||||
"properties": {
|
||||
"action": {
|
||||
@@ -257,7 +257,7 @@
|
||||
},
|
||||
{
|
||||
"name": "mobile_run_task",
|
||||
"description": "Submit a Flash/Pro Android, computer or mixed task to the user-started ARTEMIS service.\n\nDelegates a mobile workflow to a background agent. Non-blocking: returns\nimmediately with `trace_id` (for `mobile_manage_task` / `mobile_inspect_trace`),\n`device_serial`, `stdout_log`/`stderr_log` paths, and `notes_dir` (Pro only).\nCompletion notifications depend on the caller's configured notification backend;\nconversation_id alone does not guarantee the agent client receives a wakeup.\n\n### Model selection (routing)\n- **Flash** (default, preferred): simple, deterministic tasks with a clear\n UI path. No step cap by default (history is compressed, and the agent\n can recall earlier steps and query the session recording), but no ADB\n shell, no pre-execution safety net, no persistent plan or notes, and\n no midway checkpoints or persistent written notes. An exit-only read-only\n Checker judges the prompt's expectations and returns test_result;\n execution completion is separate from test pass. Unsuitable for exploration,\n multi-branch recovery, structured monitoring/polling, or tasks that\n must report back large amounts of detail.\n- **Pro**: complex, exploratory, or multi-branch tasks; continuous\n monitoring/polling; tasks needing ADB shell, system logs, verified\n checkpoints, multi-step planning, or detailed written output (via notes\n and `expected_output_desc`).\n\nFor interactive case design use mobile_exploration: user guidance, demonstration\nanalysis and reusable case generation. It has independent model settings.\nInference time varies by model, network and device; do not subtract a fixed\nper-step estimate from required waits. Deterministic test code needs explicit\ntiming and state-based waits verified against the real application.\n\n### Follow-up\n1. Poll mobile_manage_task at reasonable intervals (usually 30–60 seconds)\n while following a task; do not assume an unconfigured background notification.\n2. Read test_result and view_report after completion. Inspect relevant request,\n log or step evidence for failures and unexplained waits.\n3. Read Pro notes when its plan or detailed output is relevant to the user.\n\nReuse request_id for retries of the same submission; lookup with\nmobile_manage_task(action=\"lookup\", request_id=...). Never repeat a task\nwith a fresh ID merely because its admission reply was lost.\n\nArgs:\n request_id: Stable caller-generated ID (letters, numbers, _ or -, up to 100).\n task_desc: Clear, self-contained task description with all context,\n exact UI actions, and termination conditions (execution is one-shot).\n For Pro, may also specify what the subagent must record in its notes.\n conversation_id: Optional conversation ID used to route the completion\n wakeup notification back to the caller. Omit if unknown.\n model: `\"Flash\"` or `\"Pro\"` — see model selection above.\n locked_app_package: Optional package name to lock execution to; the\n agent auto-launches it and restricts actions to that app.\n app_path: Optional local APK path to install before running.\n expected_output_desc: Optional, Pro only. If set, a summarization agent\n writes a report to `output.md` in `notes_dir`. Ignored for Flash.\n device_serial: Optional device serial (e.g. \"emulator-5554\") to bind\n execution to a specific device; distinct devices run concurrently.\n If omitted, an available device is selected automatically. When\n several devices are attached, confirm the target with the user first\n (`adb devices -l` lists serials and authorization states).\n verification_level: Optional, Pro only. Coarse Checker preset: `\"off\"`\n (no audit; the Operator self-reports), `\"final\"` (one exit review\n against the goal, the default), `\"checkpoints\"` (every plan\n checkpoint is verified + exit review), `\"strict\"` (checkpoints with\n a larger repair budget; a failed assert halts the run). Ignored for\n Flash.\n explorer_mode: Optional, Pro only. Explorer perception version used\n by the Operator: `\"flash\"` (1-shot detection, the default),\n `\"pro\"` (3-turn ReAct), `\"ultra\"` (deep pixel reasoning; slowest).\n Ignored for Flash.\n runtime_overrides: Optional TaskOptions JSON for this task only. Supports\n execution_target ('android', 'computer', 'mixed') and plugins\n ([{id, profile}] references to saved authorized configurations; never secrets).\n Omitted plugins selects matching enabled defaults; [] disables plugins.\n Default Android tasks can use mixed extensions on demand without changing targets.\n Computer tasks require an observation plugin, not an Android device.\n Query mobile_workspace first; installation/authorization is in the plugin page.\n timeout_seconds (total execution, default 1800; excludes queue/pause),\n observation_timeout_seconds (60), observation_max_attempts (3Line truncated
|
||||
"description": "Submit a Flash/Pro Android, computer or mixed task to the user-started ARTEMIS service.\n\nDelegates a mobile workflow to a background agent. Non-blocking: returns\nimmediately with `trace_id` (for `mobile_manage_task` / `mobile_inspect_trace`),\n`device_serial`, `stdout_log`/`stderr_log` paths, and `notes_dir` (Pro only).\nAdmission normally returns `status=\"pending\"`; it does not mean the worker\nis running. A newer worker state is returned when already available.\nCompletion notifications depend on the caller's configured notification backend;\nconversation_id alone does not guarantee the agent client receives a wakeup.\n\n### Model selection (routing)\n- **Flash** (default, preferred): simple, deterministic tasks with a clear\n UI path. No step cap by default (history is compressed, and the agent\n can recall earlier steps and query the session recording), but no ADB\n shell, no pre-execution safety net, no persistent plan or notes, and\n no midway checkpoints or persistent written notes. An exit-only read-only\n Checker judges the prompt's expectations and returns test_result;\n execution completion is separate from test pass. Unsuitable for exploration,\n multi-branch recovery, structured monitoring/polling, or tasks that\n must report back large amounts of detail.\n- **Pro**: complex, exploratory, or multi-branch tasks; continuous\n monitoring/polling; tasks needing ADB shell, system logs, verified\n checkpoints, multi-step planning, or detailed written output (via notes\n and `expected_output_desc`).\n\nFor interactive case design use mobile_exploration: user guidance, demonstration\nanalysis and reusable case generation. It has independent model settings.\nInference time varies by model, network and device; do not subtract a fixed\nper-step estimate from required waits. Deterministic test code needs explicit\ntiming and state-based waits verified against the real application.\n\n### Follow-up\n1. Poll mobile_manage_task at reasonable intervals (usually 30–60 seconds)\n while following a task; do not assume an unconfigured background notification.\n2. Read test_result and view_report after completion. Inspect relevant request,\n log or step evidence for failures and unexplained waits.\n3. Read Pro notes when its plan or detailed output is relevant to the user.\n\nReuse request_id for retries of the same submission; lookup with\nmobile_manage_task(action=\"lookup\", request_id=...). Never repeat a task\nwith a fresh ID merely because its admission reply was lost.\n\nArgs:\n request_id: Stable caller-generated ID (letters, numbers, _ or -, up to 100).\n task_desc: Clear, self-contained task description with all context,\n exact UI actions, and termination conditions (execution is one-shot).\n For Pro, may also specify what the subagent must record in its notes.\n conversation_id: Optional conversation ID used to route the completion\n wakeup notification back to the caller. Omit if unknown.\n model: `\"Flash\"` or `\"Pro\"` — see model selection above.\n locked_app_package: Optional package name to lock execution to; the\n agent auto-launches it and restricts actions to that app.\n app_path: Optional local APK path to install before running.\n expected_output_desc: Optional, Pro only. If set, a summarization agent\n writes a report to `output.md` in `notes_dir`. Ignored for Flash.\n device_serial: Optional device serial (e.g. \"emulator-5554\") to bind\n execution to a specific device; tasks share the global serial queue.\n If omitted, an available device is selected automatically. When\n several devices are attached, confirm the target with the user first\n (`adb devices -l` lists serials and authorization states).\n verification_level: Optional, Pro only. Coarse Checker preset: `\"off\"`\n (no audit; the Operator self-reports), `\"final\"` (one exit review\n against the goal, the default), `\"checkpoints\"` (every plan\n checkpoint is verified + exit review), `\"strict\"` (checkpoints with\n a larger repair budget; a failed assert halts the run). Ignored for\n Flash.\n explorer_mode: Optional, Pro only. Explorer perception version used\n by the Operator: `\"flash\"` (1-shot detection, the default),\n `\"pro\"` (3-turn ReAct), `\"ultra\"` (deep pixel reasoning; slowest).\n Ignored for Flash.\n runtime_overrides: Optional TaskOptions JSON for this task only. Supports\n execution_target ('android', 'computer', 'mixed') and plugins\n ([{id, profile}] references to saved authorized configurations; never secrets).\n Omitted plugins selects matching enabled defaults; [] disables plugins.\n Default Android tasks can use mixed extensions on demand without changing targets.\n PC-only tasks use {\"execution_target\": \"computer\"}; no Android device or\n emulator needs to be online. Computer tasks require an observation pLine truncated
|
||||
"inputSchema": {
|
||||
"properties": {
|
||||
"task_desc": {
|
||||
|
||||
Reference in new issue
Block a user