app

AI Flow

Public Made by Adom

by adom

Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board.

kicadpcbedaroutingplacementcopper poursablationcurrent densitythermalkelvincomparison
Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity
Closed bug report

macOS desktop (ab 1.9.224) has no recorder: every step warns 'Unknown desktop command: desktop_record_stop'

Drew Owens · ·closed by John Lauer

adom-aiflow 0.2.20 · adom/core 4.15.3 · Adom Bridge 1.9.224 on macOS 26.3.1 (MacBook Air, Apple silicon), KiCad bridge plugin 0.11.1 · KiCad 10.0.7

Every step on this run printed the same warning, so no step has a clip:

WARNING: clip pours-4 has no file: the recorder's stop of rec-1793050158426 gave no file: Unknown desktop command: desktop_record_stop

The macOS Adom Bridge on this desktop (1.9.224) has no recorder verbs. AI Flow starts a recording anyway and finds out at the stop.

Expected: check the desktop's verb catalog (or bridge_readiness) once, say at start or on the first step that the box cannot record clips, and fall back to the start and end screenshots it already takes. That way the clips page and the video plan know before the run reaches deliver.

2 Replies

Drew Owens ·

More precise: this macOS Adom Bridge (1.9.224) does have a window recorder, under other verb names. Asked for desktop_record_status, it answers:

'desktop_record_status' is not a built-in desktop verb. Did you mean: desktop_record_window_status, desktop_permission_status, desktop_record_window_start?

So the built-in verbs here are desktop_record_window_start and desktop_record_window_status, while AI Flow calls desktop_record_start and desktop_record_stop (the Windows 2.x names). The puppeteer bridge on this Mac (2.0.396) also declares the desktop_record_ and desktop_recorder_ prefixes, but ab answers desktop_* as core verbs first, so those calls never reach it.

AI Flow could use the macOS names when the box offers them, or at least say once at start which recorder the box has.

John Lauer ·

Fixed in adom-aiflow 0.2.24. Your reply was right: on the Mac, desktop_record_window_start worked, so takes did start. Only desktop_record_stop failed, which left takes running until the one-hour cap.

  • One check per box: the first step asks the box once, read-only (desktop_record_status, which starts nothing), and caches the answer in run.json.
  • Windows 2.x recorder: clips work as before.
  • No recorder (the box says "not a built-in desktop verb" or "Unknown desktop command"):
    • The run says once "no recorder on ", naming the window verbs the box offered.
    • It starts no takes.
    • Each step keeps its start and end screenshots.
    • The clips page and deliver each say it once.
    • capture start and the 3D and fields walkthroughs refuse on that box.
  • Unclear answer (offline or timed out): nothing is cached, and it asks again next step.
  • Why the Mac recorder isn't used yet: I couldn't confirm the macOS stop verb's name, arguments or reply, and there's no Mac on our side to test. If you can post what desktop_record_window_status returns during a take, and the stop verb your box offers, I'll wire the Mac recorder in.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.24.

John Lauer closed this ·

Log in to reply.