AI Flow

AI Flow takes over the user's screen: every step raises KiCad or Hydrogen to the front

Seen on: adom-aiflow 0.2.40 to 0.2.44, the AM32 ESC run (adom/am32-esc-2s6s-molecule) on the user's own Windows PC (Hydrogen local workspace, Adom Bridge on the same machine, KiCad 10.0.6).

What happened: throughout the run, KiCad (and Hydrogen) kept being brought to the foreground while the user was working on their own PC. The user had to fight the AI for their own computer. In the source this is by design:

• step (main.rs, capture block) calls bring_front on Hydrogen at every new phase and on 11 "Hydrogen steps". It calls it on KiCad's PCB editor on every board step: desktop_bring_to_front with "show KiCad for this step".
• capture open → Bridge::open_board (aiflow-bridge lib.rs) opens the board with foreground: true, maximises the PCB editor, then brings it to the front again.
• tour 3d maximises the 3D viewer and brings it to the front.

The comments say "on the test box". On a Hydrogen local workspace, the test box is the person's own desktop, and the run has 25 steps plus every return.

The only off switch is the environment variable AIFLOW_AUTO_CAPTURE=off. The skill never mentions it, and it also turns off the step clips.

Why it is wrong: AI Flow exists so the AI can work on the board while the person does something else. Taking the screen defeats that, and it is unsafe: a keystroke or click meant for the person's own window can land in KiCad. The window recorder already used for clips (Windows Graphics Capture) is background-capturable, as the code itself notes, so filming does not need the foreground. The window only must not be minimised.

Suggested fix:

1. Never take the foreground on the person's own machine unless they said so.
   • Default screen: "hands-off" whenever the target is the machine the human is using (Hydrogen local workspace, or ab reports an active interactive session), and keep the current behaviour only for a declared test box (--target <box> with screen: "allowed").
   • In hands-off mode, skip desktop_bring_to_front and maximize in step, capture open and tour 3d.
   • Open the board un-maximised, without focus.
   • Record by window capture. If a window is minimised or fully hidden when a clip needs it, record a skipped clip with the reason (as issue #59 already does for idle windows) and say so in the run README, rather than raising it.
2. Make it a preference, recorded in run.json and shown on the timeline: screen: hands-off | ask | allowed. Let a person change it mid-run ("you can take my screen now" → allowed until they say otherwise).
3. Questions to the human are the one exception, also by preference: notify: toast | toast+sound | hydrogen-only | none.
   • A toast (ab notify_user) or a Hydrogen notification, never a window raise.
   • The answer can come back through the toast's buttons or the chat.
4. Document both in SKILL.md, next to "Capture, so the engines' videos line up", and in the foreground-etiquette skill.

A per-user preference system for this (and for how much the AI does on its own at each step) is being proposed in a separate PR, "hands-on AI Flow", which will link here.