42 lines
3.0 KiB
Markdown
42 lines
3.0 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Observe-Think-Act-Observe execution loop
|
|
The system SHALL execute a task as a repeating loop: observe the current Scene, decide the next step, act via a capability tool call, then observe the resulting Scene again, continuing until the goal is met, a failure ceiling is hit, or the task is cancelled.
|
|
|
|
#### Scenario: Loop continues until goal is met
|
|
- **WHEN** a task with a natural-language goal (e.g. "open Taobao and search Mac mini") is started
|
|
- **THEN** the runtime repeats observe→think→act until the Planner/Executor determines the goal has been reached, then marks the task complete
|
|
|
|
#### Scenario: Loop stops after max steps
|
|
- **WHEN** a task exceeds a configured maximum number of steps without reaching its goal
|
|
- **THEN** the runtime stops the loop and marks the task as failed with a reason, instead of looping indefinitely
|
|
|
|
### Requirement: Planner produces a step plan from goal and current Scene
|
|
The system SHALL provide a Planner that, given a goal and the current Scene, produces an ordered list of intended next steps (e.g. "find search box", "tap it", "type query").
|
|
|
|
#### Scenario: Planner emits steps for a new goal
|
|
- **WHEN** the Planner is invoked with a goal and the current Scene at the start of a task
|
|
- **THEN** it returns a non-empty ordered list of intended steps for the Executor to attempt
|
|
|
|
#### Scenario: Planner re-plans after unexpected Scene
|
|
- **WHEN** the Executor reports that the Scene after an action does not match what the current step expected
|
|
- **THEN** the Planner is invoked again with the updated Scene to produce a revised step (or remaining steps)
|
|
|
|
### Requirement: Executor performs retry and wait handling around tool calls
|
|
The system SHALL provide an Executor that translates a planned step into one or more capability tool calls, and SHALL retry with backoff and/or wait-for-element behavior when a step's expected result is not immediately observed, up to a configured retry ceiling.
|
|
|
|
#### Scenario: Executor retries a transient failure
|
|
- **WHEN** a tool call (e.g. `tap`) does not produce the expected Scene change on the first attempt
|
|
- **THEN** the Executor retries the step up to a configured number of attempts before treating it as failed
|
|
|
|
#### Scenario: Executor gives up after retry ceiling
|
|
- **WHEN** a step has failed for the configured maximum number of retries
|
|
- **THEN** the Executor records the step as failed and surfaces this to the Planner/task result instead of retrying forever
|
|
|
|
### Requirement: Task context/memory available during a run
|
|
The system SHALL maintain an in-run context (recent Scene history, executed steps, and their results) accessible to the Planner and Executor for the duration of a task, so re-planning decisions can reference what has already been tried.
|
|
|
|
#### Scenario: Re-planning uses prior step history
|
|
- **WHEN** the Planner is re-invoked mid-task
|
|
- **THEN** it has access to the steps already attempted in this task and their outcomes, not just the current Scene in isolation
|