## 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