What happens
TinyComputer's own saved Kashmir flow (crates/tinycomputer-examples/tasks/kashmir/plan.json) no longer gets past IndiGo's booking widget when replayed on v0.7.0. The same happens with a new Delhi→Denpasar (Bali) flow.
Setup:
- v0.7.0, loaded through the TinyBus loader by OpenHuman.
- Jev and the planner/rescuer over OpenRouter.
- A freshly launched, headed Google Chrome (
browser.executable), not an attached CDP session.
Two separate problems show up.
1. The city picker's search box cannot be targeted
choose { what: "the destination city selector", option: "Srinagar" }:
click button "To Going to? Search by place/airport" ok
type to filter INVALID_TARGET
note: "Srinagar" was not found in the destination city selector
After the click, later steps and every rescue report that the page reads as "scrolled to its footer" and that the booking widget is not visible. Scrolling steps then fail with "the last three actions changed nothing on screen". The source-city picker behaves the same way (From Delhi, DEL … → type to filter → INVALID_TARGET).
Google Flights steps (browse, wait_for, pick, verify) pass every time on the same runs.
2. The safety classifier refuses a navigation tab labelled "Book"
The planner and the rescuer both write "open the flight search form" steps. Every one fails:
refused to press tab "Book" inside an ordinary step: it looks irreversible; a flow must use stop_before for that
The rescuer explains the problem each time ("opening its flight-search form was mistaken for booking, though it does not book a flight") but cannot change the outcome, so the task spends all five rescues and fails.
A control with role tab whose label is "Book" is navigation, not a commit. It should probably classify as reversible, or at least be something a rescue can override.
Reproduce
Replay the Kashmir flow with task_live against a fresh Chrome launch (not TINYCOMPUTER_BROWSER_ENDPOINT), or run OpenHuman's tests/computer_bali_live_e2e.rs with:
COMPUTER_E2E_TASK_FILE=…/tasks/kashmir/task.md
COMPUTER_E2E_FACTS_FILE=…/tasks/kashmir/facts.json
COMPUTER_E2E_FLOW_FILE=…/tasks/kashmir/plan.json
The recorded Kashmir pass in docs/technical/evals/2026-09-29-bus-runners.md used the person's own Chrome over CDP. That may be the difference for (1).
Host PR with the harness and full step/rescue reports: tinyhumansai/openhuman#6761
What happens
TinyComputer's own saved Kashmir flow (
crates/tinycomputer-examples/tasks/kashmir/plan.json) no longer gets past IndiGo's booking widget when replayed on v0.7.0. The same happens with a new Delhi→Denpasar (Bali) flow.Setup:
browser.executable), not an attached CDP session.Two separate problems show up.
1. The city picker's search box cannot be targeted
choose { what: "the destination city selector", option: "Srinagar" }:After the click, later steps and every rescue report that the page reads as "scrolled to its footer" and that the booking widget is not visible. Scrolling steps then fail with "the last three actions changed nothing on screen". The source-city picker behaves the same way (
From Delhi, DEL …→type to filter→INVALID_TARGET).Google Flights steps (
browse,wait_for,pick,verify) pass every time on the same runs.2. The safety classifier refuses a navigation tab labelled "Book"
The planner and the rescuer both write "open the flight search form" steps. Every one fails:
The rescuer explains the problem each time ("opening its flight-search form was mistaken for booking, though it does not book a flight") but cannot change the outcome, so the task spends all five rescues and fails.
A control with role
tabwhose label is "Book" is navigation, not a commit. It should probably classify as reversible, or at least be something a rescue can override.Reproduce
Replay the Kashmir flow with
task_liveagainst a fresh Chrome launch (notTINYCOMPUTER_BROWSER_ENDPOINT), or run OpenHuman'stests/computer_bali_live_e2e.rswith:The recorded Kashmir pass in
docs/technical/evals/2026-09-29-bus-runners.mdused the person's own Chrome over CDP. That may be the difference for (1).Host PR with the harness and full step/rescue reports: tinyhumansai/openhuman#6761