Adom Bridge

ab still ships a native APS (Autodesk) implementation, and it now actively misleads users

APS is Autodesk Platform Services. It exists solely to talk to Autodesk, which makes it Fusion-specific by definition — and the boundary we both work to says the host-app integration belongs to the bridge:

AD core owns: the adom-bridge CLI, the relay / command passthrough, bridge lifecycle, and the core desktop_* verbs. That's it. The fusion bridge owns: every fusion_* verb, the APS integration (auth/config/quota), the add-in, its skills.

I suspect this predates the fusion bridge owning APS and simply never got removed. Raising it now because it stopped being merely redundant.

It is live, not vestigial

Measured on AdomLapper today:

adom-bridge --target AdomLapper aps_status {}
=> { "ok": true, "configured": false, "signedIn": false,
     "_hint": "No APS client id configured. One-time setup: register an app at
               https://aps.autodesk.com ... set its Callback URL to
               http://localhost:8910/aps/callback, then put the Client ID in ab
               config (aps_client_id) or Settings." }

Why this is a bug and not just untidiness

1. The hint leads a user to a dead end. A user who follows it registers localhost:8910/aps/callback and puts the client id in ab config — and their Fusion verbs still do not work. The fusion bridge reads a completely different store and needs different callbacks. I verified the stores share nothing:

get_client_id() in our aps.py reads only our own file (or FUSION_APS_CLIENT_ID). There is no fallback to ab's value in either direction. So "signed in" on one side means nothing to the other, and a user can be simultaneously configured and broken.

2. Two near-identical verb names, and the wrong one looks fine. aps_status vs fusion_aps_status. The bare one returns ok: true, configured: false, which reads as a benign "not set up yet" rather than "you are calling the wrong surface". An AI picking by name will pick wrong roughly half the time, and get a success envelope when it does.

3. It costs us a permanent workaround. Our callback ports are 8917/8918/8920 specifically to avoid 8910, and that reasoning is a comment in our source. We register six callback URLs on the APS app partly to route around a port ab holds for a feature nobody drives.

What I am asking for

Whichever you prefer — this is your call, not mine:

• Remove aps_* from ab and let fusion_aps_* be the only surface, or
• Delegate: keep the verb name for compatibility but have it forward to the fusion bridge when installed, so one config and one token store serve both, or
• At minimum, retire the hint. If removal is disruptive, please change the _hint to point at fusion_aps_signin / fusion_aps_set_client_id. That alone stops the dead end, and it is a one-line change.

If ab's Settings UI exposes an APS client-id field, say so and I will factor that in — that would explain why this stayed and would change the right answer.

The general point

I do not think this is a pattern in ab: the desktop_* / bridge split is clean everywhere else I touch it, and bridge_install / the relay have never leaked host-app specifics into my lane. This looks like one piece of pre-split history rather than a habit. Flagging it as the one place where "ab stays generic, the bridge owns everything about its host app" does not hold today.

Happy to do the work if you would rather I sent a PR than a request.