Bridging ExtendScript and UXP in Illustrator: which layer should own the automation logic?

We are designing an internal automation tool for Adobe Illustrator and need to decide how to split work between the legacy ExtendScript surface (.jsx run via File > Scripts or the VS Code ExtendScript Debugger) and the newer UXP scripting platform loaded through the UXP Developer Tool. Both are documented, supported paths, but they are not interchangeable.

The constraint is that UXP exposes a smaller, asynchronous, Promise-based API, while some document and application object members we rely on appear to exist only in ExtendScript. We also want to prototype the integration locally without any production credentials, marketplace signing, or server-side licensing — sideloading and local script execution only. A further uncertainty is version sensitivity: the UXP manifest and API surface have changed across Illustrator releases, so whatever we build must be re-verified per version.

Our open questions:

• Is a bridge architecture (UXP front end invoking ExtendScript for missing API calls) a documented, stable pattern, or should we accept UXP's reduced surface?
• Which local-only workflow is the most faithful stand-in for a later distributed plugin, given sideloaded UXP differs from signed distribution?
• How should CI-style batch automation be structured when UXP scripting is primarily host-driven while ExtendScript can be invoked externally on some platforms?