Which FR5 SDK does the working laptop really load?

The two launchers use different interpreters and imported copies, though both folders are labelled current; I have those paths and signatures saved now.

Have the maintainer select the supported library and call for the controller version, then make the launcher use that defined environment. Preserve the working set while comparing; copying a familiar folder can conceal the original difference.

Did the error report come from the normal user account, Jack, or from someone testing the script in a separate terminal?

Normal account and shortcut on both; maintainer found the rebuilt shortcut's interpreter imports an older shared SDK whose method has the different argument list.

Then the launcher is part of the fix. Keep the interpreter, dependency and call together in the setup record, not three separate notes that can drift apart.

Does any other application still need that shared copy?

Anna's question is why a dedicated environment is useful here. Correct this script's dependency selection without replacing a shared library another application may still require.

The shared copy serves an older teaching example, so it stays; our identity check now has a dedicated supported environment and a revised launcher, with the documented call unchanged.

Has the normal shortcut completed the actual identity read, including after closing and reopening?

Yes, correct controller identity from the normal shortcut and after reopen, with the expected imported path; the maintainer also checked it under the covering shift's account.

Remove the obsolete shortcut from the shared launch location. Otherwise the next person can select the old environment perfectly correctly.

Obsolete shortcut removed from that location, working replacement checked by the covering operator; thanks, Anna, we fixed this job without breaking the teaching example beside it.

Who owns updating that environment when the script next changes?