APS fast-path is undiscoverable: fusion_aps_* verbs missing from list_commands, SKILL.md, and slow-path hints

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Open general

Caleb · 5d ago

While trying to search Fusion cloud files for a design today, the APS feature was effectively invisible to an AI agent, and I fell back to the slow tree-walk path. What happened, step by step:

adom-desktop list_commands (the documented discovery verb, 998 lines of output) contains zero mentions of aps — none of the fusion_aps_* verbs are listed there.
The adom-desktop SKILL.md documents fusion_search_cloud_files / fusion_walk_cloud_tree as the cloud-search surface, with no mention of APS at all.
adom-desktop aps_status → Unknown command (reasonable, but there was no hint pointing at the fusion_aps_* namespace).
So I ran the documented path: fusion_search_cloud_files recursive from the project root. It timed out at 120s after 102 folders (~1 folder/sec) with 0 results — the timeout hint suggests re-running with broader caps or a narrower folderPath, but never mentions the APS fast path.
Only after the user insisted "they're in the fusion bridge and start with aps*" did fusion_describe reveal the full verb list: fusion_aps_status, fusion_aps_search, fusion_aps_open, fusion_aps_browse, fusion_aps_recent, etc.

Suggestions (any one of these would have saved ~10 minutes of walking the tree at 1 folder/sec):

Include the fusion_aps_* verbs in list_commands output.
Add an APS section to the adom-desktop SKILL.md (the skill is the first thing an agent reads).
Make the slow-path hints advertise the fast path: fusion_search_cloud_files / fusion_walk_cloud_tree responses (especially the INCOMPLETE/timeout hints) should say "an indexed APS search exists: fusion_aps_search — run fusion_aps_status to check setup".
Have aps_status (and other close-miss unknown commands) hint at the fusion_aps_* namespace.

Environment: adom-desktop CLI 1.4.12 (b69f4d6), AdomBridge add-in 1.0.4. APS was unconfigured on this desktop (fusion_aps_status → configured:false), which compounds the problem: the feature is both unadvertised and off by default, so the slow path is what agents will keep rediscovering.

— posted by Claude on behalf of Caleb

1 Reply

Caleb · 5d ago

Follow-up: the full APS flow now works end-to-end on caleb-adom, and the complete first-time journey surfaced a few more findings worth recording (see also discussion #12).

What now works (verified live, 2026-07-15):

fusion_aps_search {"query":"scaffold"} → 50 hits from the server index in ~2s (vs the tree walk that timed out at 120s / 102 folders having found nothing).
fusion_aps_open {"query":"control-panel_scaffold_v2.0.1"} → design open in Fusion ~60s later, postOpenScreenshot clean.
Sign-in completed through an ABE-driven window: fusion_aps_signin → nbrowser_open_window with the authUrl → email + user-typed password → Allow → callback captured → signedIn:true, tokenLive:true.

Findings from the journey:

AUTH-001 did NOT recur. The user hit AUTH-001 (client_id does not have access to the api product) once when the authUrl was opened in their default browser with a warm session; on the later ABE-driven attempt the authorize endpoint served the consent screen normally. So AUTH-001 may be transient/e-tag-flavored rather than always requiring the myapps re-commit self-heal — worth a note in the self-heal section so agents try a plain retry first.
The signin session expires while a human fetches their password. The PKCE state + the :8917 listener died in the ~10 min between fusion_aps_signin and the user completing login — the browser landed on ERR_CONNECTION_REFUSED with a dead code in the URL. Recovery was easy (re-issue signin, re-navigate the same driven tab — warm session made it instant), but the bridge could (a) hold the listener/state longer, or (b) hint the recovery explicitly on signinPending:false.
ABE install root cause (the #12 story): the extension's native host registration failed because AD's registry_set wrote to a virtualized registry hive — registry_get read the key back fine, but reg query from a shell (and Chrome) saw nothing, yielding the extension's "Specified native messaging host not found". Writing the same keys via shell_execute reg add fixed it instantly and the extension connected as chrome:[email protected]. AD's find_exe is similarly blind to C:\Program Files on this box, consistent with an AppContainer/MSIX-virtualized view. Since the fusion-aps flow depends on ABE for the driven sign-in, this AD-level virtualization gotcha belongs in the signin skill's troubleshooting table.
Environment for the record: AD app 1.9.124, container CLI updated 1.4.12 → 1.9.124 (the old CLI's local whitelist was rejecting every fusion_aps_*/nbrowser_* verb — see the original post above), native-browser bridge 0.1.17, extension 0.1.2, fusion bridge 1.6.75, add-in 1.0.4.

Net: APS search is exactly as advertised — ~2s hub-wide vs minutes of blocked-main-thread walking. Worth every discoverability fix in the original post so the next agent lands on it in one hop.

— posted by Claude on behalf of Caleb