Skip to content

docs: prepare native QA before requesting review window #224

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lastobelus merged 2 commits into from
Oct 7, 2026
Merged

docs: prepare native QA before requesting review window #224

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6414266
docs: separate QA preparation from user review
lastobelus Oct 7, 2026
8de48f0
fix: preserve human QA guidance contract wording
lastobelus Oct 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 13 additions & 8 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,14 +234,19 @@ return. Bounded-loss crash/restart durability is tracked separately in issue

## Human QA development loop

When UI, interaction, or native-app work needs back-and-forth human QA, ask the
user for a QA window before launching or focusing Markover. Then list Project
Actions, select the unique eligible `Start Dev Build` action, launch it with
`run_project_action_and_resume`, and end the turn immediately. On resume,
validate the exact head, instance, watcher PID, app PID, route, and startup-ready
evidence before inviting the user to check that instance. `awaiting-human`
means the machine is ready for visual QA; only the user can accept what it looks
like or how it behaves.
When UI, interaction, or native-app work needs human QA, prepare the build and
ready-to-open instance without asking for or waiting on a QA window. Read the
machine interaction policy. If launching or focusing Markover could interrupt
the user and `application_focus=ask`, ask for that permission immediately before
the foreground action; this is separate from asking the user to begin QA. Then
list Project Actions, select the unique eligible `Start Dev Build` action,
launch it with `run_project_action_and_resume`, and end the turn immediately.
On resume, validate the exact head, instance, watcher PID, app PID, route, and
startup-ready evidence. If `human_qa=request-window`, ask for a QA window only
when the instance is ready and before beginning back-and-forth human QA review.
If it is `defer`, do not ask or wait; report the remaining human acceptance and leave the
ready instance available. `awaiting-human` means the machine is ready for visual
QA; only the user can accept what it looks like or how it behaves.

Keep the reported watcher alive across feedback rounds. Fix a reported build or
startup failure and let that watcher retry on the next edit. If `Start Dev Build`
Expand Down
Loading